athenian200 wrote: ↑2024-03-08, 05:48
Essentially, the whole situation seems to be proving Mozilla right, and showing that XUL is just too powerful for the average end user to be able to handle, because the average user doesn't want their extension to be a full-blown JavaScript runtime environment that can touch any part of the browser almost, they want something simple and limited that will let them do a few extra things, and which fails gracefully if anything goes wrong. That's part of why I find thinking about NoScript to be demoralizing... it just seems like a situation that goes a long way towards proving Mozilla right and makes me question what I have been doing working on a project like this, whether it's even viable... you know what I mean?
I know where you're coming from, but at the same time I have to remind you that there are tens of thousands of extensions that were made, vetted and accepted for Firefox. They were safe to use and didn't do anything untoward. The problem is that you're drawing what is clearly a massive outlier in as being "the normal state of things". It is not. It's a mental trap you should avoid here. Just one bad extension doesn't mean the XUL extension framework is bad. It just means that you have to be more careful and not use calls that reach deep into the browser guts
unless you know
exactly what you are doing and are intimately familiar with the intricacies of the parts you touch, and keep a close eye on any changes in code you call into and update your extension side to accomodate. Abandoned extensions clearly will not do the latter, and they will break sooner or later; the more advanced the interaction with the browser core, the faster that will happen. NoScript doesn't
have to do its script blocking in the way it does, but its developer
chose to do it that way. Since he walked away 6 years ago before things like Shadow DOM, JS modules, JS preloading, multiple document roots and more advanced JS internals were a thing, NoScript has simply started to mismatch what it is extending and it
needs to be maintained
like any other extension to keep pace with browser development.
As a side note: I chose to make this a new milestone for a reason. We crossed another threshold under the hood. And this seems to be some of the fallout from it.
andikay wrote: ↑2024-03-08, 04:29
Nonetheless, it doesn't make the addon less popular and when it was working in PM 32.5.2 but it's crashing in 33.0.x then it's quite clear that it's not suddenly the addon that has changed, so some change in browser code had to be responsible for it.
Not necessarily. On the surface it may seem that it's some bug introduced in the browser that now crashes, but it just seems to me that v33 simply exposed something that the extension is doing that is no longer gracefully recovered from because surrounding code changed on the browser side. The extension did something wrong before, but it didn't lead to a crash until now. I have an inkling it may be related to our JS module code as I do think there's a conflict with how NoScript blocks JS and how we are now expected to dynamically load and unload whole JS module scripts on-the-fly. e.g. what happens when a module script is loaded internally, but NoScript prevents it? Suddenly there's nothing for the compiler to process. Etc Etc.
I'm not sure how those two dance together under the hood.
The previous "NoScript patch" was also for a situation that in normal circumstances would simply never occur, but with NoScript it did. When we change code in the JS engine, we have to take into account the (already complex) environment it is in, but can't take into account every possible contingency that doesn't logically follow from our own code, as Athenian already explained above.
.
.
