[4.1][NO CACHE] Remove the math.div deprecation

[dgrammatiko]

Pull Request for Issue # .

Kinda replaces #36906 (no FA upgrade to v6)

Summary of Changes

• patch the font awesome files
• upgrade to choices v10
• local fixes

Testing Instructions

• Apply this Pr's branch
• run npm ci
• Check that nothing is broken visually and there are no console deprecation when running any node (css related) cli command

Actual result BEFORE applying this Pull Request

Expected result AFTER applying this Pull Request

Documentation Changes Required

@brianteeman @bembelimen

[bembelimen]

I guess the vue file is wrong?

[dgrammatiko]

No, they are correct. It’s the result of npm run lint:js — —fix

[HLeithner]

The silent upgrade of choices.js is a b/c break

[dgrammatiko]

The silent upgrade of choices.js is a b/c break

it wasn't silent, check the description. Also fixing XSS is ok even if It breaks things (security is always no1).

Anyways I think someone else should try, IU had my fair chances and it didn't worked out

[dgrammatiko]

@HLeithner for reference I saw it coming and tried to fix things here: #33773 but people were against it

[HLeithner]

ok but why do you close this PR if you only write in the title that you fix the math.div deprecation?
If it's a security thing you should report it to the jsst.

[dgrammatiko]

If it's a security thing you should report it to the jsst.

There's nothing to report again, I raised my concerns when the choices was introduced to J4. Also there is no real B/C break as the default behaviour still allows innerHTML according to their docs:

This behaviour has been deprecated. The new option allowHTML has been introduced, with the current default to true.

Ref: https://github.com/Choices-js/Choices/releases/tag/v10.0.0

[HLeithner]

I would say that's a b/c?

As a result of this change, callbackOnCreateTemplates now receives the full configuration object, instead of just classNames. The method signature to match previous versions is now ({ classNames }, data). See the documentation for the updated example.

[dgrammatiko]

I would say that's a b/c?

Did you or anyone else used the callback? Theory says yes this is B/C break, practically there are close to 0% changes that someone will be affected by this, or any of the changes due to the upgrade

[HLeithner]

that's the problem I can't say it so I can only read the b/c and then I can say we are using semver for js or not.
It's not possible for me to check all dependencies if a b/c break would happen for us or any of our users.

But as always please join the discussion if and where Joomla should use semver joomla/rfc#29

if you think semver is (partly) a bad idea then please share your opinion and we may remove semver for Joomla if this fit better the needs for our users and us.

But just making exception everywhere doesn't make sense that mean we don't make semver but only saying we do and break things expected for users. If it's a security thing then the jsst have to solve it (or course with your help).
The solution can be we update to 10. or backport the fix.

[dgrammatiko]

The solution can be we update to 10. or backport the fix.

There's another option:

• Remove the upgrade to v10
• Use own SCSS files for the choices (as I did in the other PR before upgrading)

[HLeithner]

tbh I don't understand what you mean? removing choices? and what has it todo with the scss in this case?

[dgrammatiko]

@HLeithner check #37255

Also have some tests and either merge it or if it goes out of sync close it. I spent more time that I'm comfortable in this one.

Thanks

[HLeithner]

Thanks, I reported the XSS to JSST in your name.