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.
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.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre
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)...
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre
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.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101015 Firefox/4.0b8pre
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.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101015 Firefox/4.0b8pre
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).
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.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101016 Firefox/4.0b8pre
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.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b8pre) Gecko/20101012 Firefox/4.0b8pre
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!
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101018 Firefox/4.0b8pre