I hope it is possible to update Mootools script to avoid such error.

IIRC, MooTools 1.5 had compatibility breaks that makes upgrading the library a bad idea.

I don't know how many times I reported that the com_privacy introduced Mootools in the front end for no reason (that was in 2019 not a decade ago). FIX IT

Also I'm regretting that I never did a PR to introduce a new set of editor button (ext buttons) like 5-6 years ago. That would have eliminated for good Mootools with the only disadvantage that version 3 would had 2 sets of editor buttons (the core would have used the new ones but the old ones -mootools based- would be also available, although I guess all devs would had dropped them). Well we can't turn back time, that's my regret or my mistake...

As far as I understand, @dgrammatiko 's proposal of having 2 sets of editor buttons would be a progressive feature enhancement, i.e. bring new feature enhancements without breaking existing ones, and as far as I understood recent motions from Production Department, we allow this now, so the proposal could be implemented in J3.

@HLeithner What do you think about it?

@Sulpher if you have a custom template and don't use frontend editing (and com_privacy) mootools shouldn't be loaded. I'm sure you find a plugin in JED that removes mootools from the frontend or replace it's with a newer version. That com_privacy uses mootools in the frond could be maybe overritten by a templates/layout override?

And upgrading mootools in J3 seams to be a b/c break stated by michael. Doesn't mean you can try to do it by your self.

@Sulpher if you have a custom template and don't use frontend editing (and com_privacy) mootools shouldn't be loaded. I'm sure you find a plugin in JED that removes mootools from the frontend or replace it's with a newer version. That com_privacy uses mootools in the frond could be maybe overritten by a templates/layout override?

I am using the front-end and com_privacy.
Since Mootools is a core part of Joomla, I guess using 3rd party extension can be considered as a temporary solution only.

Of course, the best way is to rewrite the code to avoid using Mootools as a heavy library, but I guess it is possible in J4 only...

In J4 mootools has been removed already.

That com_privacy uses mootools in the frond could be maybe overritten by a templates/layout override?

@HLeithner if only people took my comments seriously: #20051 (comment)

Brian asked for help, we missed a chance that can only be fixed in j4... I hope that there is no framework needed in frontend in j4 for any core component but I don't know if some layouts simply pull jquery or what ever. Should be checked before beta.

I hope that there is no framework needed in frontend in j4

That was my plan with the custom elements: https://github.com/joomla-projects/custom-elements But the last time I tried to bring it to production state and asked for some a11y help I was attacked and therefore I dropped the idea. Also my plan was to have every and each form field as a custom element for two very self explanatory reasons:

• Custom elements are truly dev friendly (controlled with some element attributes instead of messing in some weird js init function)
• they're the best way (at least that I know) to go out of the hard Bootstrap/Fonta Awesome/Whatever lock-in

It's not that Joomla has to have hard dependencies, it's a decision (not mine). I seriously tried for years to make this project more friendly (even to not devs) but the resistance is very real...

Brian asked for help, we missed a chance that can only be fixed in j4

@HLeithner you're wrong, follow the discussion and you'll find that I even tried to give him some code (although not tested because probably I was working on J4 and couldn't just switch for a stupid echo renderModal().
Also this IS still fixable for J3. Add another layout and make it default for all the new installations. In the release that has this change also mention that people should switch the Layout to the new one (if their site is BS based, or even if it's not, but you can't make that change for them).

I hope that there is no framework needed in frontend in j4

That was my plan with the custom elements: https://github.com/joomla-projects/custom-elements But the last time I tried to bring it to production state and asked for some a11y help I was attacked and therefore I dropped the idea. Also my plan was to have every and each form field as a custom element for two very self explanatory reasons:

• Custom elements are truly dev friendly (controlled with some element attributes instead of messing in some weird js init function)
• they're the best way (at least that I know) to go out of the hard Bootstrap/Fonta Awesome/Whatever lock-in

It's not that Joomla has to have hard dependencies, it's a decision (not mine). I seriously tried for years to make this project more friendly (even to not devs) but the resistance is very real...

I personally see NO javascript the best option if not absolutely needed. So webcomponents should be avoided if they bring no gain to a field.

But that's my opinion.

I personally see NO javascript the best option

I will agree to some degree, the point is that there is needed functionality that is not yet (or will never be) available in the platform. It's true that you could get far without any JS but it will be impossible for all the provided functionality in a Joomla form (validation, subforms, WYSIWYG editors, etc)...

If you try to integrate some e.g. a Vue.js project inside Joomla that uses Core-JS many extensions just fail because of different implementations of Array.from.

Couldn't this get configurable so that we get a build of mootools that allows modern JS without errors or hacking the mootols-core file manually. (Currently i'm just replacing Array.from with Array.convert)

Or a Version select wich version of Mootools to use? As Mootools 1.6 fixed this according to this Blogpost.

So... Joomla 3.10 was the last version with new features and adding such a switch would really be a new feature. By that, we can't introduce such a switch for J3.x anymore and for J4 this issue is solved by not including mootools at all anymore. For 3.x, you can use third party extensions to remove mootools. Thus I would vote to close this issue as WONTFIX.

That's right. Closing for the reasons stated above.