Closed Bug 1065998 Opened 5 years ago Closed 5 years ago

delayedStartup doesn't finish on certain Windows 8 systems where the theme's ColorizationColor is not set, breaking the menu panel / about:customizing

Categories

(Firefox :: Toolbars and Customization, defect)

32 Branch
x86_64
Windows 8.1
defect
Not set
Points:
1

Tracking

()

VERIFIED FIXED
Firefox 35
Iteration:
35.2
Tracking Status
firefox32 --- wontfix
firefox33 --- verified
firefox34 --- verified
firefox35 --- verified

People

(Reporter: hackl.schorsch, Assigned: Gijs)

References

Details

(Whiteboard: Workaround in comment #33)

Attachments

(2 files)

Attached file about_support_raw.txt
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140825202822

Steps to reproduce:

New laptop (X1 Carbon) - fresh installation of FF32. The menu button does no work and I cannot access about:customizing. Everything else works, including synching my regular profile, all addons coming with it, accessing about:config etc. Reseting FF, complete de-installation with deleting of profile, keys etc. does not do the trick.


Actual results:

Menu button does not open
Bookmark bar disappears (reappears when deactivated / activated in menu bar)


Expected results:

Menu button opens as on my other installations of FF32
About:customizing opens
Component: Untriaged → Toolbars and Customization
Thanks
Safe mode has no effect. 
Creating a new profile, renaming, deleting all or one profile in manager: still cannot open menu button.
When you enter about:customizing in a new tab, what do you see? A blank page?
Yes, completely empty, only the FF logo turns orange:
https://dl.dropboxusercontent.com/u/19639676/tmp/about_customizing.PNG 

When I click the menu button, nothing happens.
Try to disable you antivirus/firewall if you have any
I deactivated both ESET and all windows features and restated FF. No effect.
Gijs, do you have any idea ?
Flags: needinfo?(gijskruitbosch+bugs)
FYI: I started in safe mode, FF starts but the button does not work.
I mean Windows safe mode
This is very strange. However, when we say "safe mode" we mean Firefox's "restart with add-ons disabled" option, in the Help menu. Please try using that and see if the problem goes away in there - the Windows' safe mode has nothing to do with that. I expect an add-on and/or malware is breaking the button, and that would be a good way to test.

The other thing that'd be helpful is if you could try the following:

1) open Firefox
2) go to Tools > Web Developer > Browser Console
3) hit the "Clear" button at the top
4) click the menu button
5) copy/paste any errors that show in the browser console here.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(hackl.schorsch)
Are you able to open the "Menu" dialogue by clicking on the icon in the toolbar: http://i.imgur.com/ZhZEakZ.jpg

Because on the French community board, someone has a similar issue. So maybe it's the same than yours.
@Loic: I referred to this as "menu button" - it does not open.

@Gijs: as described in Comment 2 FF Safe mode had no effect either.

As for Console. Hitting menu button did not record anything. 

Entering about:customizing, however, lead to:

this._cps2 is undefined browser.js:1702
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName] urlbarBindings.xml:944
this._cps2 is undefined browser.js:1702
Flags: needinfo?(hackl.schorsch)
I... have no idea. Do other panels work, like the downloads panel?
Yes. About:config, plugins etc. All panels Bookmarks etc. it all works. 

Now it only shows: this._cps2 is undefined browser.js:1702 
In the meantime I deactivated a few plugins by moving the files...not sure about causality.

Thanks for the effort already
We might need to give hackl.schrosch a specially instrumented build with some logging if we're going to figure out what's going wrong here...
OK, so I've gathered some more ideas about what could be wrong here...

In the Browser Console that I asked you to use before, is there a line at the bottom to evaluate JS? If not, go to the web console (Tools > web developer > console), click the gear icon on its toolbar, and make sure the checkbox for "enable chrome and add-on debugging" is checked. Then reopen the browser console.

Then in the input line, put in the following and hit enter:

PanelUI.show()

(this should open the menu panel, but I'm guessing it won't work)

Then try:

PanelUI.panel.setAttribute("animate", "false");
PanelUI.show();

Does that work?

If it does, can you also confirm that the menu panel works fine on Firefox 30? (NB: don't use that for long, it's got known security issues)

If all that doesn't work, can you tell me what this shows in the browser console if you evaluate it:

gBrowserInit.delayedStartupFinished

?

Thanks for helping us figure this one out!
Flags: needinfo?(hackl.schorsch)
hello,
i am in the french community; since ff 31 i can't open le menu button; i can open it in ff 30 but "about:customizing give me a blank page.

thank you

(In reply to Loic from comment #11)
> Are you able to open the "Menu" dialogue by clicking on the icon in the
> toolbar: http://i.imgur.com/ZhZEakZ.jpg
> 
> Because on the French community board, someone has a similar issue. So maybe
> it's the same than yours.
hello,
i am in the french community; since ff 31 i can't open le menu button; i can open it in ff 30 but "about:customizing give me a blank page.

thank you

(In reply to Loic from comment #11)
> Are you able to open the "Menu" dialogue by clicking on the icon in the
> toolbar: http://i.imgur.com/ZhZEakZ.jpg
> 
> Because on the French community board, someone has a similar issue. So maybe
> it's the same than yours.
Sorry for late response, trips, no internet etc...

(In reply to :Gijs Kruitbosch from comment #17)
> PanelUI.panel.setAttribute("animate", "false");
> PanelUI.show();
GIVES: 
TypeError: PanelUI.panel is undefined

> If it does, can you also confirm that the menu panel works fine on Firefox
> 30? (NB: don't use that for long, it's got known security issues)
I tried the FF30 portable and it works. The portable FF32 has the same issue...so I think this is a valid
 
> If all that doesn't work, can you tell me what this shows in the browser
> console if you evaluate it:
> gBrowserInit.delayedStartupFinished
GIVES: false

PS: For non-developers. A) The concole and gear options etc. only show when you click on "Toogle Tools", there is no console...it took me a bit. Hence, B) It would be good if you have a set f screenshots you can refer to somewhere to guide newbies like me.
Flags: needinfo?(hackl.schorsch)
(In reply to hackl.schorsch from comment #20)
> Sorry for late response, trips, no internet etc...

Don't worry! I am on a trip myself now, so I might be a bit slow myself - I totally understand. :-)

> (In reply to :Gijs Kruitbosch from comment #17)
> > PanelUI.panel.setAttribute("animate", "false");
> > PanelUI.show();
> GIVES: 
> TypeError: PanelUI.panel is undefined

Aha. Note to self: we're failing somewhere before: https://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js?rev=eba49b6a540a#1092 (because if PanelUI.init() had run, PanelUI.panel wouldn't be undefined)


> > If it does, can you also confirm that the menu panel works fine on Firefox
> > 30? (NB: don't use that for long, it's got known security issues)
> I tried the FF30 portable and it works. The portable FF32 has the same
> issue...so I think this is a valid

Great!

> > If all that doesn't work, can you tell me what this shows in the browser
> > console if you evaluate it:
> > gBrowserInit.delayedStartupFinished
> GIVES: false

Right...

> PS: For non-developers. A) The concole and gear options etc. only show when
> you click on "Toogle Tools", there is no console...it took me a bit. Hence,
> B) It would be good if you have a set f screenshots you can refer to
> somewhere to guide newbies like me.

Sorry! Glad you figured it out anyway. This info really helps. So basically, when we open a new firefox window (the first or the however-many-th, it doesn't really matter), we run a method right after the window is opened that does a bunch of setup stuff. It's called "delayedStartup", and it looks like in your case, something in it is broken and so it doesn't finish, and because opening the menu panel waits on that having happened, it never opens. The same happens for about:customizing.

Next thing to figure out is *why* it doesn't finish running. I'm hopeful that there's an error in the same browser console. So can you try following these steps:

1) open Firefox
2) go to Tools > Web Developer > Browser Console
3) hit the "Clear" button at the top
4) open a new Firefox window

and let us know any errors/warnings that show up? If the only one that shows up looks like this:

> OpenGL compositor Initialized Succesfully.

with a bunch more lines mentioning your graphics card, can you try downloading a nightly build zip from here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-35.0a1.en-US.win32.zip

and running the steps with that instead? We recently added some better error reporting, so it might be worth trying if that helps us in getting an error message we can work with. If not, I will have to start creating builds with extra error reporting from that function to figure out why it fails...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(hackl.schorsch)
Summary: Cannot access menu button / about:customizing → delayedStartup sometimes doesn't finish and therefore menu panel / about:customizing doesn't work
Mike, how evil do you think wrapping all of delayedStartup in a try...catch() with a bundle of error reporting is (and always firing the observer notification + setting the bool to true from there) ? Ie, basically making it infallible despite whatever happens inside it?
Flags: needinfo?(mconley)
(In reply to :Gijs Kruitbosch from comment #22)
> Mike, how evil do you think wrapping all of delayedStartup in a
> try...catch() with a bundle of error reporting is (and always firing the
> observer notification + setting the bool to true from there) ? Ie, basically
> making it infallible despite whatever happens inside it?

I don't see the point. Errors should be reported either way. If that's somehow not happening or insufficient, we need to fix that.

If your code waiting for browser-delayed-startup-finished isn't actually interested in whether delayed startup finished successfully, it should probably use different means...
(In reply to :Gijs Kruitbosch from comment #21)
Thanks, this is what I get in FF 32 and with the nightly build

TypeError: customizationColor is undefined Windows8WindowFrameColor.jsm:26
TypeError: aNode is null nsContextMenu.js:508
TypeError: gContextMenu is null browser.xul:1
Flags: needinfo?(hackl.schorsch)
(In reply to Dão Gottwald [:dao] from comment #23)
> (In reply to :Gijs Kruitbosch from comment #22)
> > Mike, how evil do you think wrapping all of delayedStartup in a
> > try...catch() with a bundle of error reporting is (and always firing the
> > observer notification + setting the bool to true from there) ? Ie, basically
> > making it infallible despite whatever happens inside it?
> 
> I don't see the point. Errors should be reported either way. If that's
> somehow not happening or insufficient, we need to fix that.
> 
> If your code waiting for browser-delayed-startup-finished isn't actually
> interested in whether delayed startup finished successfully, it should
> probably use different means...

I think most consumers here are usually interested in a particular part of delayed startup having finished, and currently any failure will immediately break everything else, too.

Alternatively, we could try to come up with a mechanism so that failures in the initialization of one part of the function don't break the rest of the function (ie right now, if FullZoom.init throws, nothing after it gets run - it'd be better if that wasn't the case).
Blocks: 940393
(In reply to hackl.schorsch from comment #24)
> (In reply to :Gijs Kruitbosch from comment #21)
> Thanks, this is what I get in FF 32 and with the nightly build
> 
> TypeError: customizationColor is undefined Windows8WindowFrameColor.jsm:26
> TypeError: aNode is null nsContextMenu.js:508
> TypeError: gContextMenu is null browser.xul:1

Perfect. Now I can fix this. :-)

Just to have some context, misterloup and hackl.schorsch, do you use particular theme software and/or did your machine come with a manufacturer-provided theme or something like this? It seems like a registry key we rely on in Windows 8 isn't there where we were expecting it to always be there...
Flags: needinfo?(misterloup)
Flags: needinfo?(hackl.schorsch)
(In reply to :Gijs Kruitbosch from comment #25)
> I think most consumers here are usually interested in a particular part of
> delayed startup having finished, and currently any failure will immediately
> break everything else, too.

What part of delayed startup is customization code interested in? Can it query that more explicitly?

I think we should probably spin this off to a separate bug, though, and concentrate on the Windows8WindowFrameColor.jsm failure here.
(In reply to Dão Gottwald [:dao] from comment #27)
> (In reply to :Gijs Kruitbosch from comment #25)
> > I think most consumers here are usually interested in a particular part of
> > delayed startup having finished, and currently any failure will immediately
> > break everything else, too.
> 
> What part of delayed startup is customization code interested in? Can it
> query that more explicitly?

PanelUI.init. It could probably nullcheck PanelUI.panel, but that doesn't get you an observer notification of sorts. We could add one, but that wouldn't have helped here - I'd rather we make the different bits of that method independent of each other.

> I think we should probably spin this off to a separate bug, though, and
> concentrate on the Windows8WindowFrameColor.jsm failure here.

For sure.
Summary: delayedStartup sometimes doesn't finish and therefore menu panel / about:customizing doesn't work → delayedStartup doesn't finish on certain Windows 8 systems where the theme's ColorizationColor is not set, breaking the menu panel / about:customizing
I'm away from my win8 machine until Monday night, but from the screenshot from mozfr, this seems to be the correct color... but it doesn't match frameBaseColor? Jared, can you check if this makes sense? Likewise, what happens if the second value is missing - is halfway a correct guess or not? Not taking this because it seems like this patch might need more iterations and I'm not in the right position to check this myself until Monday. :-(
Attachment #8491432 - Flags: review?(jaws)
In my opinion, we should do everything in our power to ensure that as much of the browser is usable as possible in the disaster scenario (something throws in delayedStartup).

I think we should:

1) Ensure anything that goes wrong in delayedStartup gets logged to the console
2) Do best effort to recover when a single step of delayedStartup fails. Maybe that means wrapping a bunch of those init functions in a try-catch, or wrapping them with an infallability function or something. The outcome is the same - more resilience to failure during delayedStartup.
Flags: needinfo?(mconley)
misterloup has posted a screenshot about the values of "ColorizationColor" and "ColorizationColorBalance" in "HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM", it's empty: http://i.imgur.com/nLCKbaM.png

I asked to another Firefox user with no issue, his reply:
ColorizationColor = 0xc4ffffff (3305111551)
ColorizationColorBalance = 0x00000059 (89)
(In reply to :Gijs Kruitbosch (Mostly gone until 22/9) from comment #26)
> Just to have some context, misterloup and hackl.schorsch, do you use
> particular theme software and/or did your machine come with a
> manufacturer-provided theme or something like this? It seems like a registry
> key we rely on in Windows 8 isn't there where we were expecting it to always
> be there...

My IT-colleague "fixed" it based on your comment...the button appears but the problem prevails.

-Background:
We are distributing new laptops with an image installation. FF works fine at first as the local admin does not have the "menu button problem" imaged or not. With registering / logging-in into my old mirrored Win7 profile (which is then pulled from the server) the problem appears for my local account (and others).

-My - not working - Theme:
Exactly(?) the theme as in Win7. My old theme had only a background colour of black which appeared on my new Win8 machine as it was on Win7. The theme was not saved and had no name.

-Solution:
Change the background colour...I "changed" it to one-colour black by clicking the buttons. It is still status "unsaved" but the FF menu button works now. I assume with "changing" the theme, the registry values Loic mentioned are filled. I have now: 
ColorizationColorBalance = 0x00000059 (89) (and many other entries)

-Impact:
If this truly happens with the process described in -Background- it will reappear and cause many people to scratch their heads as they might think they screwed up their image etc. 

-Microsoft:
I think....they should be notified as well as it likely to be the root cause (also for other software) but you know better how to do it...
Flags: needinfo?(hackl.schorsch)
I confirm the workaround given by the reporter, the user needs to select a color ("Automatic" is enough) in the menu about the color of window borders and taskbar (Control Panel > Appearance and Personalization >  Personalization > Color and Appearance) to fill the missing variables in the registry.

After selecting the "Automatic" choice: 
1) Values in registry: http://i.imgur.com/bUjGx9Q.png
2) about:customizing tab: http://i.imgur.com/nJ9NhTb.png
Flags: needinfo?(misterloup)
Comment on attachment 8491432 [details] [diff] [review]
empty-check Windows8WindowFrameColor's customizationColor in case its registry value is gone,

Review of attachment 8491432 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the following change, and after you confirm that the change works as you intended on your Win8 machine.

::: browser/modules/Windows8WindowFrameColor.jsm
@@ +32,5 @@
>      customizationColorHex = ("00000000" + customizationColorHex).substr(-8);
>      let customizationColorArray = customizationColorHex.match(/../g);
>      let [unused, fgR, fgG, fgB] = customizationColorArray.map(function(val) parseInt(val, 16));
>      let colorizationColorBalance = Registry.readRegKey(HKCU, dwmKey,
> +                                                       "ColorizationColorBalance") || 0.5;

colorizationColorBalance is divided by 100 two lines lower to get the alpha value (0-1), so this value should be 50 if we want it to have .5 alpha.
Attachment #8491432 - Flags: review?(jaws) → review+
The colorvalues match my system when I delete the keys and/or slide the intensity slider all the way to the left (different values - 158,158,158 vs. 217,217,217). If I delete the colorbalance value, log out and log back in, I get back 0x4e (78) so I guess that should be our default, too. I can also confirm that with the patch included and the registry values deleted, opening the menu button and customize mode both work.

I'll check in the updated patch per comment #34 and 78 instead of 50, and I'll file a followup for making delayedStartup more error-resilient.
... 3 push races later:

remote:   https://hg.mozilla.org/integration/fx-team/rev/20aa550e49bb

and I filed bug 1071182.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/20aa550e49bb
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 35
Egh, just realized I totally forgot to get this into the backlog. We should uplift this post-verification. 

Marco, can you add this to the iteration spreadsheet, and would it be possible to get this verified sooner rather than later? I'd really like this to still make 33 if possible.
Iteration: --- → 35.2
Points: --- → 1
Flags: qe-verify+
Flags: needinfo?(mmucci)
Flags: in-testsuite-
Flags: firefox-backlog+
Added to IT 35.2.

(In reply to :Gijs Kruitbosch from comment #38)
> Egh, just realized I totally forgot to get this into the backlog. We should
> uplift this post-verification. 
> 
> Marco, can you add this to the iteration spreadsheet, and would it be
> possible to get this verified sooner rather than later? I'd really like this
> to still make 33 if possible.
Flags: needinfo?(mmucci)
Hi Kairo, can a QA contact be assigned for verification as per Gijs' request in Comment #38.
Flags: needinfo?(kairo)
I triage the list of qe-verify+ bugs without a QA contact regularly anyhow so a specific ni? is usually not needed, but I guess it sped up things here by a few hours this time. :)
Flags: needinfo?(kairo)
QA Contact: cornel.ionce
Comment on attachment 8491432 [details] [diff] [review]
empty-check Windows8WindowFrameColor's customizationColor in case its registry value is gone,

Per discussion with Sylvestre, asking for aurora approval now to get more users on this patch. I'll ask for beta approval hopefully after verification, before the last beta next week...

Approval Request Comment
[Feature/regressing bug #]: bug 940393
[User impact if declined]: on certain windows 8 machines, the main menu panel won't open
[Describe test coverage new/current, TBPL]: nope :-(
[Risks and why]: reasonably low, just made the module getting windows 8 windowframe colors more resilient to stuff that otherwise breaks it
[String/UUID change made/needed]: nope
Attachment #8491432 - Flags: approval-mozilla-aurora?
Attachment #8491432 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I was unable to reproduce this issue on three different machines running Windows 8.1 64-bit so I cannot confirm if this fixes it or not.

Could you please confirm that this issue is no longer reproducing on your side using latest Firefox Nightly?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
Flags: needinfo?(hackl.schorsch)
(In reply to Cornel Ionce [QA] from comment #43)
> I was unable to reproduce this issue on three different machines running
> Windows 8.1 64-bit so I cannot confirm if this fixes it or not.

I'm not sure what you're running into. To reproduce:

1. Install old build
2. Open regedit using the windows run dialog
3. Under:

HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM

delete the following two keys:

ColorizationColorBalance
ColorizationColor

4. Open the old build you've installed
5. Click the menu button.


Then repeat with the newer build. In the older build, the menu doesn't open. In the newer one, it does.

Does this help with reproducing the issue?
Flags: needinfo?(cornel.ionce)
Thank you Gijs!
I was able to reproduce the issue using an older Nightly build.

Confirming the fix for latest Nightly, build ID: 20140925030203 on a Microsoft Surface Pro 2 device running Windows 8.1 64bit.
Flags: needinfo?(hackl.schorsch)
Flags: needinfo?(cornel.ionce)
Comment on attachment 8491432 [details] [diff] [review]
empty-check Windows8WindowFrameColor's customizationColor in case its registry value is gone,

Approval Request Comment
[Feature/regressing bug #]: bug 940393
[User impact if declined]: on certain windows 8 machines, the main menu panel won't open
[Describe test coverage new/current, TBPL]: nope :-(
[Risks and why]: reasonably low, just made the module getting windows 8 windowframe colors more resilient to stuff that otherwise breaks it; fix is verified on trunk
[String/UUID change made/needed]: nope
Attachment #8491432 - Flags: approval-mozilla-beta?
Attachment #8491432 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Also verified on Latest Aurora, build ID: 20140926004004 and the Menu button is working accordingly.
Verified fixed on Firefox 33 beta 8, build ID: 20140929180120.
Status: RESOLVED → VERIFIED
Whiteboard: Workaround in comment #33
Duplicate of this bug: 1075208
You need to log in before you can comment on or make changes to this bug.