Fonts dialog has two problems. 1. Combobox for Sans-serif and Monospaces are broken. 2. I set size for 16pt but Size in Fonts dialog is "9" Steps to reproduce: 1. Open Preferences(Linux) or Options(Windows). 2. Click Advanced button. Original bug report in Japanse is http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=5909. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007102823 Minefield/3.0a9pre

Also on Windows XP. Regression range is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1193430360&maxdate=1193444099 so it is caused by Bug 345711. A bit weird but I double-checked it.

(In reply to comment #1) > Also on Windows XP. > Regression range is > http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1193430360&maxdate=1193444099 > so it is caused by Bug 345711. > A bit weird but I double-checked it. > I also verified this as a regression from bug 345711 via back-out.

This results in 2 occurrences of the following error in the error console: Error: preference.setElementValue is not a function Source file: chrome://browser/content/preferences/fonts.js Line: 51

When I originally open the Fonts dialog on Windows Vista, I don't see the exact problem shown in the screenshot, I just see empty comboboxes for Sans-serif and Monospace. I do see the font size being shown at 9 (instead of 16). However, when I change the "Fonts for:" combobox to something else (other than the default Western), everything seems to work OK. And it seems to be fine when I put it back to Western. (In reply to comment #3) > This results in 2 occurrences of the following error in the error console: > > Error: preference.setElementValue is not a function > Source file: chrome://browser/content/preferences/fonts.js > Line: 51 I don't see any errors in the error console. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007102705 Minefield/3.0a9pre ID:2007102705

(In reply to comment #4) > I don't see any errors in the error console. Well, do you have the display of errors occurring in chrome enabled? Set the preference javascript.options.showInConsole to true.

(In reply to comment #5) > Well, do you have the display of errors occurring in chrome enabled? > > Set the preference javascript.options.showInConsole to true. Thanks for pointing that out; I just changed that pref, and now I do see the 2 errors in the error console.

Better steps to reproduce are: 1. Open Preferences(Linux) or Options(Windows). 2. Select "Content" section. 3. Click Advanced button. 4. Try to choose Sans-serif or Monospace font. Actual results Comboboxes are broken

Fixes a number of issues: 1. Makes sure we call InstallImplementation on all queued bindings before running any constructors 2. Makes us not bail even if an InstallImplementation called failed. We'll simply remove that binding from the queue and keep chugging away at it. 3. Makes us call InstallImplementation on newly queued bindings even if we're in the middle of ProcessAttachedQueue. This ensures that code that runs in a constructor will still be able to access the implementation of content it creates. All three seemed to be problem in our or extension chrome. I also added a check to make sure that if the document gets destroyed while processing the attached-queue we won't clobber mProcessingAttachedStack. This fix is unrelated to the filed bugs, but something that probably needs to be fixed.

Comment on attachment 286898 [details] [diff] [review] Patch to fix Looks good to me! r+sr=jst

fine here. maybe other regressions from bug 345711 will be fixed.

Checked in.

Are we guaranteed that we have no null entries past mAttachedStackSizeOnOutermost in nsBindingManager::EndOutermostUpdate?

No, there can be null entires anywhere in the stack. My thinking was this: As soon as we add something to the AttachedStack we'll post an event. When we post that event we'll call ProcessAttachedQueue(0) Calling ProcessAttachedQueue(0) will always produce an empty queue, if null entires exist anywhere they will be ignored.

Then we need some null-checks for the EnsureScriptAPI calls in EndOutermostUpdate?

yes, good catch.

verified fixed using the steps to reproduce from comment #0 and : - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110104 Minefield/3.0a9pre - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007110106 Minefield/3.0a9pre (on Fedora F7) - Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9a9pre) Gecko/2007110105 Minefield/3.0a9pre -> Verified

This caused bug 421997: in EndOutermostUpdate, the new code assumes there are no null pointers in mAttachedStack, but there could be some.