this is new, as of using today's comm bits on linux, at least [2000-02-04-08]. to repro: 0. check the initial state of, say, the default homepage by grep'ing your prefs.js. eg, mine said user_pref("browser.startup.homepage", "http://bugzilla.mozilla.org"); 1. open Prefs, go to Navigator panel. 2. change the default homepage to, say, http://www.google.com 3. click OK. 4. grep prefs.js to observe the [lack of] change. what's really bizarre was that for a while shrir wasn't able to repro this (same bits, same platform) till he suddenly got a crash opening prefs (see bug 26588). after restarting seamonkey, he can no longer change his homepage. moreover, this might affect all of prefs, since syd chatted with me recently about similar problems when trying to change IM prefs. syd, could you pls provide further details (which panel, platform, etc)?
nominating for beta1. added firstname.lastname@example.org, in case he has seen this. btw, lemme know if this is a dup of another, larger bug that has recently cropped up.
Seeing on mac commercial build also (2000020410m14). Changing PLATFORM and OS to ALL.
I've seen this in accounts manager: bug 26580. Haven't seen in prefs just because they keep crashing me.
*** Bug 26600 has been marked as a duplicate of this bug. ***
it looks like this was caused by brendan's JS changes last night. Looks like something broke with for (var i in associativeArray) when associativeArray is an array of arrays.
This is dying the interpreter changes that brendan made last night. This does not look like a front end problem at all
If you back out brendans changes then it does not crash so says danm.
oh joy. I added rogerl to cc list and I'll email brendan. I'll look into it.
With an old profile it changed the pref and all worked fine. I created a new profile and it crashed in JS when I clicked on the tree. It crashes in jsemit line 654 where cx->fp->varobj == NULL I'll attach a stack trace. and keep looking closer /* * We can't optimize if we're not compiling a function body, whether via * eval, or directly when compiling a function statement or expression. */ obj = cx->fp->varobj; clasp = OBJ_GET_CLASS(cx, obj); if (clasp != &js_FunctionClass && clasp != &js_CallClass) return JS_TRUE;
Putting on PDT+ radar for beta1.
rods saw that same crash doing File Open, which (of course!) WorksForMe. cx->fp->varobj must not be null at the crashpoint, because js_CompileTokenStream sets up a frame with varobj set to the valid JSObject pointer that was passed to JS_Compile*. Can someone able to reproduce the crash under a debugger verify that by going up the stack to js_CompileTokenStream and inspecting the "frame" local variable? /be
Argh, timeouts for the openDialog-calling window are nesting in the dialog's modal event loop. This seems bad, at least at first blush. It also exposes a logic bug in my JS changes: I assumed no one would reuse a context to compile code that's already in use for the same scope. Foolish me. Patch to fix that (and the crash) coming right up. Whether that fixes the for/in loop erratic behavior alecf saw, and helps save prefs and account state, we'll have to see. /be
Created attachment 4946 [details] [diff] [review] proposed crashbug fix -- helluva way to start a sabbatical!
*** Bug 26580 has been marked as a duplicate of this bug. ***
*** Bug 26568 has been marked as a duplicate of this bug. ***
Fix checked into js/src/jsemit.c -- why am I still here? Thanks to jband and alecf for help chasing this down. Apologies to all, /be
*** Bug 26588 has been marked as a duplicate of this bug. ***
yay! verif w/2000-02-07-08 comm bits on linux and winNT.
Bulk move of all Pref UI component bugs to new Preferences component. Pref UI component will be deleted.