PM x64 33.x crash with noscript

[Moonchild]

I understand there might be no ready alternative to NoScript for some users. But once again, if you want this situation to be resolved, then get together and update the extension so it no longer crashes the browser when active. It is literally where the line is, and has always been, drawn for extensions. I'm sorry if it inconveniences you but it is the same pretty clear bar for every single extension out there.

[moonbat]

Don't worry, it's widely known that you are not interested in being helpful towards people who refuse to follow instructions.

FTFY. I've been around long enough for my posts to speak for themselves and I wouldn't be here as an addon developer if that were the case. Then again I don't need to justify myself either.

[andyprough]

I thought maybe I'd just bring up a reason why some users don't use eMatrix. I have tried it, I simply can't use it. I am visually impaired. I have tried it. Unlike NoScript, eMatrix does not seem to follow the browser's.. gui? Font size? I am not sure of the technical terms. What I know is that NoScripts dropdown menu has the same font size as the other menus in Pale Moon. EMatrix's dropdown menu has a smaller font size. I have gone into the settings and set the font size slider to the rightmost level "bigger" but that font is still not large enough for me to be able to read it. I have tried changing it in about:config but I guess the setting is hardcoded to not go above 96px.
Furthermore I have to run my computer in high contrast mode, which eliminates a lot of colours. Whether i set eMatrix to colourblind friendly or not in the settings makes no difference, the menu doesn't show any difference between allowed or disallowed connections.

That's a good point, maybe the developer of eMatrix could add some additional font sizes and color-blind color schemes. Seems like it should be possible since it's already been done once before. You could start a new thread asking for that change with eMatrix in the Add-ons forum: viewforum.php?f=46

[andyprough]

Don't worry, it's widely known that you are not interested in being helpful. And your statement seems more like you are part of your so-hated Google Chrome consortium than anything else.

Seems like a very harsh thing to say to someone like @moonbat who volunteers large chunks of his time to build and maintain important add-ons for us. I personally think his Pure URL add-on makes Pale Moon much more useable, and I'm looking forward to see if he can finish his fork of the priv8 add-on so we can have higher quality multi-container sandboxing in Pale Moon. I'd say he's been incredibly helpful.

[oinkoink]

I understand there might be no ready alternative to NoScript for some users. But once again, if you want this situation to be resolved, then get together and update the extension so it no longer crashes the browser when active. It is literally where the line is, and has always been, drawn for extensions. I'm sorry if it inconveniences you but it is the same pretty clear bar for every single extension out there.

Do you really expect anyone affected to contribute to this ecosystem when the response on this board is so overtly hostile? I came into this debating whether I would try to help deal with compatibility, as I have done before, but at this point I'm just debating whether I'll switch back to Firefox.

[moonbat]

I thought maybe I'd just bring up a reason why some users don't use eMatrix. I have tried it, I simply can't use it. I am visually impaired.

That's a good point, maybe the developer of eMatrix could add some additional font sizes and color-blind color schemes.

eMatrix already has a color-blind friendly option in its settings, if you enable that, it changes the colors to a presumably better contrasting scheme. Give it a try.

I'd say he's been incredibly helpful.

Thank you, andyprough!

Do you really expect anyone affected to contribute to this ecosystem when the response on this board is so overtly hostile? I came into this debating whether I would try to help deal with compatibility, as I have done before, but at this point I'm just debating whether I'll switch back to Firefox.

It's not 'hostile' when one has to repeatedly point out the reasons why NoScript has been blacklisted as well as the alternative eMatrix, and why using it disqualifies the user from asking for technical help here.
And as already pointed out, you have a problem with eMatrix's update frequency while clinging on like grim death to an extension that's been abandoned for 6 years and counting
So yes, go back to Firefox by all means if you're so hung about one extension and refuse to consider the working and maintained alternative. At least the NoScript for Firefox is actively maintained for that browser and should work properly on it.

[Moonchild]

Do you really expect anyone affected to contribute to this ecosystem when the response on this board is so overtly hostile?

Pointing out the truth about extension vetting and indicating a path forward to resolve it is not "overly hostile". I think you're projecting.

[athenian200]

Do you really expect anyone affected to contribute to this ecosystem when the response on this board is so overtly hostile? I came into this debating whether I would try to help deal with compatibility, as I have done before, but at this point I'm just debating whether I'll switch back to Firefox.

Well, to be fair, most of the forum members are exasperated with hearing about NoScript issues. People have been reporting issues with it and trying to put the burden of fixing it on us for years (I think almost 7 years now?), no matter how many times we say that it causes problems and to please not come here asking for support and reporting crashes and whatnot, because we know it has issues and do not recommend its use.

The reality is, we blocked NoScript once before, and unblocked it with the understanding that people would understand it was totally unsupported, that they were on their own, and not come complaining to us about it crashing the browser or doing other undesirable things. That was not adhered to, and NoScript users came right back here, acting entitled to support because of their "needs," suggesting that we take accountability for the browser instability caused by an unsupported extension that we have consistently advised against using, but they chose to use.

The blocking of NoScript was a way of taking accountability and trying to protect users from instability and data loss since our feet were being held to the fire on that issue, even if it wasn't the form of accountability you might have liked to see. We were happy to leave NoScript users to their own devices and using their extension as long as they don't complain about it to us... but they came complaining about crashes and instability and wonky behavior after we asked them to leave us out of it hundreds of times in the past, so back on the blocklist it goes. They are going to complain about it being broken, or complain about it being blocked, so we get to deal with them being mad one way or another... and better for us to get complaints about being too authoritarian and telling users it's dangerous, than to get complaints for letting people crash their browser and suffer data loss without any kind of warning at all, if that's the choice we have to make.

That said, I do get what you're saying... we're frustrated with NoScript users because they keep trying to make their issues our problem, have not shown a willingness to look into fixing their extension to be more compatible with Pale Moon themselves, and won't take no for an answer. NoScript users, in return, are frustrated with us, see us as hostile for being dismissive and tired, and don't trust us enough to contribute to the ecosystem. It's not clear how we could move from that point, and setup a situation where NoScript users understand that they need to maintain their extension or offer up patches for Pale Moon itself if it turns out to be a bug in our codebase, and understand that we respect hard work and fixing up older extensions, but get exasperated with people dumping more on our plates when we want to focus on web compatibility and don't want to be responsible for fixing every old extension someone might want to use.

Off-topic:
Why is it always freaking NoScript, anyway, why did that have to be the one everyone insists on using against our advice and trying to force us to fix? Couldn't they have picked an easier extension that wasn't such a pain to work with that someone would actually be willing to fork and update?

That said, Firefox does indeed have an up-to-date version of NoScript, and thanks to WebExtensions being a lot more limited in scope and being more limited in how it can touch the browser internals, it probably won't crash your browser...

https://addons.mozilla.org/en-US/firefo ... /noscript/

That is what NoScript's team supports, not the version for our browser. If you are a NoScript user first and a Pale Moon user second... then yeah, you should use a browser they support. They don't support Pale Moon, and that isn't our fault. Why can't they blame NoScript for dropping XUL, instead of us for the extension not working perfectly over time as the browser changes?

[Mæstro]

As it turns out, I have diagnosed the actual glitch whereby Pale Moon v33 crashes with NoScript on the page listed. The browser thereby crashes when opening an MP4 file as though it were a web page, as I had tested by opening a local file and the same film used to test last time. This problem resembles one observed in Ⅵ 23. It had happened last time that the relevant glitch is one which can occur even for clean profiles in certain cases. Might it be so here also? Version 33 could have introduced the same regression that affected that, or another like it. I hope asking this can make this discussion more constructive. Passions always run high whenever NoScript is mentioned.

[suzyne]

Why can't they blame NoScript for dropping XUL, instead of us for the extension not working perfectly over time as the browser changes?

This.


Hasn't the social contract with extensions always been that when a browser update breaks an extension, it is purely the responsibility of the extension developers to release an update to their code? So, with the NoScript developers stating:



The suggestion that Pale Moon should (must!) be coded to accommodate an extension that even its developer don't support is quite mind-boggling to me.

[andyprough]

The browser thereby crashes when opening an MP4 file as though it were a web page, as I had tested by opening a local file and the same film used to test last time.

That's interesting, if I open that mp4 with eMatrix, even with all elements blocked, the mp4 opens and plays and there is no browser crash. So there is a difference in what noscript is doing.

Pretty cool little mp4 by the way.

[athenian200]

As it turns out, I have diagnosed the actual glitch whereby Pale Moon v33 crashes with NoScript on the page listed. The browser thereby crashes when opening an MP4 file as though it were a web page, as I had tested by opening a local file and the same film used to test last time. This problem resembles one observed in Ⅵ 23. It had happened last time that the relevant glitch is one which can occur even for clean profiles in certain cases. Might it be so here also? Version 33 could have introduced the same regression that affected that, or another like it. I hope asking this can make this discussion more constructive. Passions always run high whenever NoScript is mentioned.

Well, if it turns out the crash can be reproduced without NoScript installed, that means it is an actual bug in Pale Moon that we would then be obligated to address. The thing that's frustrating about NoScript is that it tends to introduce bugs/instability that otherwise wouldn't exist, so it's very hard to tell if anything related to it is a real problem we need to care about, or just NoScript being NoScript again.

Of course, if someone does find a way to patch around this and it doesn't hurt the browser in other ways, like regressing web compatibility, we would probably take the patch... we're not unreasonable people. But it seems like people are thinking in terms of Pale Moon being broken if NoScript doesn't work properly with it, rather than the other way around.

[Moonchild]

Well, if it turns out the crash can be reproduced without NoScript installed, that means it is an actual bug in Pale Moon that we would then be obligated to address. The thing that's frustrating about NoScript is that it tends to introduce bugs/instability that otherwise wouldn't exist, so it's very hard to tell if anything related to it is a real problem we need to care about, or just NoScript being NoScript again.

The previous situation was also just an issue that would not exist without NoScript or a similarly made extension doing the same Bad Thing™. We cannot add a million extra checks into the browser core because an extension creates an otherwise not-occurring environment/situation. That's just the wrong approach, because then we'd have to build in safeguards akin to not trusting our own code doing what it should. We have no obligation to account for a situation that is not otherwise exposed. We'd end up losing all our time and effort into obsessively checking every variable being handed off everywhere "just in case an extension does something wrong and crashes us". That's topsy-turvy. Last time we made an exception accepting the addition, but we won't keep doing that.

If XUL NoScript will no longer be updated, then fork it, fix it, and take over maintenance of it. It's clearly been abandoned. (license permitting, of course)

Of course, if someone does find a way to patch around this and it doesn't hurt the browser in other ways, like regressing web compatibility, we would probably take the patch... we're not unreasonable people.

It all depends on the patch and what needs to be "hammered shut". We may make another exception, maybe, if there's no impact otherwise, but that's where the leniency probably ends. We'd be playing whack-a-mole because NoScript by its current nature causes undefined behaviour. Once again, suitable alternatives exist that do not put stability at risk.

[athenian200]

The previous situation was also just an issue that would not exist without NoScript or a similarly made extension doing the same Bad Thing™. We cannot add a million extra checks into the browser core because an extension creates an otherwise not-occurring environment/situation. That's just the wrong approach, because then we'd have to build in safeguards akin to not trusting our own code doing what it should. We have no obligation to account for a situation that is not otherwise exposed. We'd end up losing all our time and effort into obsessively checking every variable being handed off everywhere "just in case an extension does something wrong and crashes us". That's topsy-turvy. Last time we made an exception accepting the addition, but we won't keep doing that.

Ah, I had misunderstood the situation then, I assumed the previous patch was only accepted because someone reproduced the issue without NoScript.

[Moonchild]

I assumed the previous patch was only accepted because someone reproduced the issue without NoScript.

Not as far as I know. See also dbsoft's post at viewtopic.php?f=46&t=29897&p=240070#p240033

[andikay]

I am no browser developer, just a normal developer scrub, but isn't it a good idea for any developer to not have their software crash, no matter the circumstances? If you know there are addons that are popular (besides your best efforts to get rid of them ) and could cause problems, wouldn't it be a good idea to implement general checks for addons in that regard? Whether you like it or not, a big part of why people use PM is the ability to use these older addons, flawed as they may be.

@athenian200: I always appreciate your more neutral approach to these topics, here as well as on reddit. Like I said, it always takes two to Tango and I can certainly see the issues you guys have with the problematic approach of how NoScript works. 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. It doesn't mean that the browser code is faulty, it simply means there's an issue created by the changes in conjunction with that addon.

[suzyne]

I am no browser developer

I am not a browser developer either, but I wonder if this analogy can apply?

Suppose, a vehicle manufacture requires a certain sort of fuel/oil for their engines. Should the owners of a vehicle expect to use any old combination of fuel and oil because that's their right and besides, they always used that other combination in their previous motor vehicle without any problems.

Should the manufacture have to somehow find the resources to cater for people who don't follow the minimum requirements for their engines?

For me, this comes down to trusting the judgement of Moonchild and the rest of the team. When they say they do not have the resources to, or that supporting NoScript will have a detrimental effect on the ongoing development of Pale Moon, I willingly believe them and are thankful for what Pale Moon can do, and their efforts to make it a secure and regularly updated browser that is a free alternative to the mainstream.

[Eduardolucas1]

I am no browser developer, just a normal developer scrub, but isn't it a good idea for any developer to not have their software crash, no matter the circumstances? If you know there are addons that are popular (besides your best efforts to get rid of them ) and could cause problems, wouldn't it be a good idea to implement general checks for addons in that regard? Whether you like it or not, a big part of why people use PM is the ability to use these older addons, flawed as they may be.

@athenian200: I always appreciate your more neutral approach to these topics, here as well as on reddit. Like I said, it always takes two to Tango and I can certainly see the issues you guys have with the problematic approach of how NoScript works. 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. It doesn't mean that the browser code is faulty, it simply means there's an issue created by the changes in conjunction with that addon.

I believe the best solution is to download an JS on/off extension and turn it off whenever you go into a link you don`t trust or to a site you don`t trust. problem solved. i have one and do that all the time.

Why do noscript users want a full-auto gearbox when a semi-auto is as fast, secure and not buggy?

[athenian200]

@athenian200: I always appreciate your more neutral approach to these topics, here as well as on reddit. Like I said, it always takes two to Tango and I can certainly see the issues you guys have with the problematic approach of how NoScript works. 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. It doesn't mean that the browser code is faulty, it simply means there's an issue created by the changes in conjunction with that addon.

Yeah, knowing you appreciate that helps me be less frustrated with the situation. I'll try to explain some of this in a way that suggests why adapting the browser to the extension wouldn't make a lot of sense.

Even though they're called "XUL extensions," the majority of what they do is actually more JavaScript-heavy. So when we have to make changes to how the JavaScript engine works to keep up with new web standards, old addons can begin to malfunction.

So naturally, what you might think is, "well, if the JS in an addon can cause the browser to crash, what's to stop a web page with malformed JS from crashing the browser in the same way?" And that's a good question, because in some cases that might happen. But the thing is, JavaScript running on an actual web page is limited in how it can touch the browser internals, because we don't trust web content... so it wouldn't be able to manipulate things on nearly as deep a level.

XUL extensions, by contrast, run with what we call "chrome privileges," which means it's fully trusted and is basically being treated like a part of the browser itself, just as much as the DevTools or any settings menu would be. NoScript can manipulate anything in the browser using malformed JS, not just web content, and the browser is designed around trusting its own code not to do certain things, and since extensions are effectively treated like a part of the browser itself once they are installed, them being badly written or not updated enough can cause a lot of problems.

We are walking a very fine line here with XUL. We can't put stricter limits on precisely what extensions are able to do, because if we go that route, we're basically doing what WebExtensions (Mozilla/Google) did and most of the advantages of XUL vanish. We also can't take the obvious alternative approach of hardening the browser against anything an extension might do, because that would involve a huge number of checks, turn everything into spaghetti code, and make the browser extremely slow and unusable. So if we can't limit the extensions so they don't do bad things in the first place, and can't make the browser more robust at handling misbehaving extensions, then what can we do? It would sound like we're out of options, right?

Well, the answer is that we have to rely on extensions being written properly in the first place, and discourage the use of extensions that are not well-maintained or which are known to cause problems. That's where stuff like the blocklist comes in. But what this approach means, is that our extensions are more than just simple extensions that you can install to get extra functionality and which don't break anything if something goes wrong. The browser itself is basically acting sort of like a runtime environment or a compiler, in a way... for instance, if you put bad code into a compiler, it doesn't protect you from the consequences of the bad code. It's garbage in, garbage out, it's stupid pretty much. It doesn't know what you want and it won't protect you from a stupid mistake crashing the whole browser.

So, a really good argument could be made... that Mozilla and Google made the right call in the first place by ditching XUL and going for WebExtensiosn, because most users do not have the "developer mentality" needed to handle the power of XUL extensions responsibly. I think that's one of the reasons I have such a visceral reaction to NoScript... because the situation surrounding it gives me cognitive dissonance about what I've been doing for the past few years, because I feel like the best way to solve it would be... to ditch XUL so extensions can't do stuff like this, it's just evidence that what I've been working on was towards an unrealistic goal.

Since NoScript users will not accept the idea voluntarily that extensions need to be maintained and avoided if they are not, that means we are stuck with the first two options we wanted to avoid dealing with in the first place... either harden the browser against misbehaving extensions and distrust our own code, or limit what extensions can do. And remember that we already decided hardening the browser against misbehaving extensions was unrealistic as a long-term solution. So that really seems to suggest that the only sane course of action is what Mozilla did already, and that's to create a more limited extension framework that only has content privileges and can't crash the browser, but also just can't do as much in general.

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?

Though to be fair. XUL isn't the primary reason I work on UXP... but I know that XUL is what keeps the lights on, so it worries me to see a situation that makes it seem so difficult to keep it viable.

[Kris_88]

"Build a system that even a fool can use and only a fool will want to use it."