InformAction Forums

Giorgio Maone wrote:

BarryM wrote:One other symptom I see of the latest Minefield nightly 20101014 with 2.0.3.3 is that the informational bubbles that appear during a "critical" event (like saving a password, the info message that NoScript.net was prevented from installing a new version of NoScript unless authorized, etc.) don't show the text, but the confirmation button in the bubble does appear properly.

This has nothing to do with NoScript. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=604464 for this.

David wrote:I get crashes every attempted start with NoScript enabled as well, but I don't have either "noscript.toStaticHTML" or "noscript.surrogate.enabled" entry in my about config. Should they be manually added?

You should have them. If you don't, it means your profile is severely borked or NoScript has never been installed there.

Sorry, NoScript was disabled when I checked for the entries. I set them both to false and the crashing upon opening has stopped.

Thanks.

wilberfan wrote:http://crash-stats.mozilla.com/report/i ... 0082101014

To test it, I was clicking on the "Oprah Magazine Features Runamocs" link on this page: http://www.facebook.com/SoftStarShoes It was consistently crashing with that link...

Just to confirm that the two 'about:config' tweaks solved my crashing on the above link (on Linux--haven't tried Windows yet)...

Just want to confirm that the near-constant crashes have stopped upon changing those two config options. I'm running the latest nightly build on Windows 7 x64.

Please notice that this is not a NoScript bug, and the about:config changes I suggested are to be taken as temporary work-arounds, waiting for Minefield to be fixed (bug 604368).
On a side note, I didn't manage to reproduce yet with NoScript in its default configuration.
Another known trigger is GreaseMonkey, and any extension which uses evalInSandbox() may trigger more or less often.

Since I can't edit my above post, I'd like to mention that with the above tweaks applied NoScript doesn't handle certain embedded elements properly, including video. For some users it might be more prudent to switch to another browser or disable NoScript in the meantime. I imagine this was already known, but just a heads up to those who view lots of video-intensive sites.

Thanks for confirming that it's a Minefield bug, by the way. Glad to see it's getting attention at Bugzilla. Hopefully things will be in working order in a day or two.

sea wrote:For some users it might be more prudent to switch to another browser or disable NoScript in the meantime.

For most users, "another browser" would just mean a stable Firefox 3.6.x version or latest Firefox 4 beta.
If you use trunk builds, you must expect crashes (you know, it's called "Minefield" for a reason).

Giorgio Maone wrote:

sea wrote:For some users it might be more prudent to switch to another browser or disable NoScript in the meantime.

For most users, "another browser" would just mean a stable Firefox 3.6.x version or latest Firefox 4 beta.
If you use trunk builds, you must expect crashes (you know, it's called "Minefield" for a reason).

Jeez, sorry for speaking. I'll just fuck off and die while I'm at it.

Hello,

ok, you'll accuse me of trolling, but Noscript has so much options than a lot of them are unknown for the majority of users (like me).

Why should we reenable noscript.toStaticHTML and noscript.surrogate.enabled later if Noscript works without them ?

Even after all these years, I still think there should be an extension for security, and an extension which blocks scripts, objects, frames.

pirlouy wrote:Why should we reenable noscript.toStaticHTML and noscript.surrogate.enabled later if Noscript works without them ?

Because otherwise you'll get more popunders, and many sites where you block Google Analytics will break, and so on...?
http://hackademix.net/2009/01/25/surrog ... analytics/
http://hackademix.net/2010/01/06/noscri ... op-unders/

Giorgio, thanks for the workarounds. I have been scratching my head trying to figure out why Minefield 64bit has been crashing upon loading Facebook pages (the most notable page where I can reproduce the error consistently) and the workaround seems to work.

I upgraded to the latest noscript today, reset the two settings mentioned in this thread--and FF is crashing again...

wilberfan wrote:I upgraded to the latest noscript today, reset the two settings mentioned in this thread--and FF is crashing again...

Because Firefox's bug had not been fixed yet.

Giorgio Maone wrote: Because Firefox's bug had not been fixed yet.

It's fixed in current nightly and I can confirm NoScript is now working without problem.

Okay, I just updated to Gecko/20101018 Firefox/4.0b8pre, and returned the two options mentioned above to "true". All seems well. I really appreciate how quickly you respond to these issues! Thank you!