947581 - WindowsPrefSync.jsm errors on startup

Status: RESOLVED WONTFIX

(Firefox :: General, defect, P2)

Description

[Jesse Ruderman]

This is happening on startup on w64-ix-slave156 and many others.  I can't reproduce on fuzzer-win1, which is running Windows 7.

Could not pull for prefType 64: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIToolkitProfileService.selectedProfile]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/WindowsPrefSync.jsm :: <TOP_LEVEL> :: line 79"  data: no]

Could not pull for prefType 128: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIToolkitProfileService.selectedProfile]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/WindowsPrefSync.jsm :: <TOP_LEVEL> :: line 79"  data: no]

Could not pull for prefType 32: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIToolkitProfileService.selectedProfile]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/WindowsPrefSync.jsm :: <TOP_LEVEL> :: line 79"  data: no]

Comment 1

[Brian R. Bondy [:bbondy]]

We can skip this code to only run on win8, but I'm not sure if that will cover whatever problem is happening here though.  Is your build using any special build flags?

Comment 2

[Brian R. Bondy [:bbondy]]

Do you know if your build is metro compatible? If you took it on a win8 machine would it have metro?

Comment 3

[Brian R. Bondy [:bbondy]]

Sounds like this is an x64 only issue too right? 
Also just to confirm does it have any other side effects than showing up in the log?

Comment 4

[Jesse Ruderman]

My script just grabs the Tinderbox debug builds from https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32-debug/.  I don't have remote desktop access to the machines where this happened, so I don't know if there were other symptoms.

Comment 5

[Brian R. Bondy [:bbondy]]

p=1 I think this is just a console spam message that we should not display

Comment 6

[Marco Mucci [:MarcoM]]

Hey Stephen, can you provide a point value and I'll add it to IT#21.

Comment 7

[Stephen A Pohl [:spohl]]

Setting this to p=2 to investigate why selectedProfile might be null, and to determine the proper way to suppress the console spam if that's determined to be the right solution.

Comment 8

[Brian R. Bondy [:bbondy]]

I think it might be related to the keys not existing because the other front end wasn't launched yet.

Comment 9

[Stephen A Pohl [:spohl]]

Jesse, would you be able to attach the full console output for a run that reproduces this problem? There should be other warnings/errors that lead up to the failures reported here. Thanks!

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I can see the same set of console messages while running our Mozmill tests against latest versions of Nightly. Each time the browser restarts those are getting dumped to the console. Those are a bit more detailed regarding the line of code which is failing:

Could not pull for prefType 64: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIToolkitProfileService.selectedProfile]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/WindowsPrefSync.jsm :: this.WindowsPrefSync.prefRegistryPath :: line 79"  data: no]

Could not pull for prefType 128: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIToolkitProfileService.selectedProfile]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/WindowsPrefSync.jsm :: this.WindowsPrefSync.prefRegistryPath :: line 79"  data: no]

Could not pull for prefType 32: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIToolkitProfileService.selectedProfile]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/WindowsPrefSync.jsm :: this.WindowsPrefSync.prefRegistryPath :: line 79"  data: no]

Affected code:
http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/WindowsPrefSync.jsm#74

Comment 11

[Stephen A Pohl [:spohl]]

I'm unable to reproduce this on Windows 8.1 or Windows 7, by manually starting Firefox or running Mozmill locally. I'm not comfortable making a change to suppress these messages since it could mask a greater problem. A full console log of a run with this problem might give us a better idea of what's going on.

Comment 12

[Allison Naaktgeboren :ally]

re-nominating for triage. This seems stuck

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: mozmill log.txt

Stephen, as attached you can find a full log of our mozmill testrun. Here for the functional tests for a Nightly build on Windows 8 32bit.

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

I can reproduce the issue when launching older profiles (which are basically new profiles with some test settings tweaked and test extensions like for showing the error console at the bottom installed). The issue doesn't happen with a new profile.

These errors prevent Firefox from switching to Metro mode. Steps to reproduce (latest Nightly, Aurora and Beta):
1. Launch old profile.
2. Customize the toolbar and add the Windows 8 tile icon (or use the Firefox button on Beta).
Actual result: Splash screen shown, closes and back to the desktop screen.
3. Open a command line and create a new profile.
4. Repeat step 2 with this profile.
Actual result: Firefox launches in Metro mode.
5. Switch back to desktop mode, feel free to simply close the profile manager.
6. Launch the old profile.
7. Click on the Metro mode button.
Actual result: Old profile launches in Metro mode.
8. Switch back to desktop mode.
9. Launch the profile manager and delete the new profile created in step 3.
10. Launch the old profile again.
11. Try to switch to Metro mode.
Actual result: Splash screen shown, Firefox quits.

It seems like Firefox tries to find the metro profile from the registry where it isn't set or not set anymore.

The error is thrown here: http://mxr.mozilla.org/mozilla-central/source/toolkit/profile/nsToolkitProfileService.cpp#554

The difference a new profile makes seems to be the line "Default=1" in the profiles.ini. Before creating the new profile and after deleting it, that lines doesn't exist in my profiles.ini.

Comment 15

[Benjamin Kerensa [:bkerensa]]

(In reply to Archaeopteryx [:aryx] from comment #14)
> I can reproduce the issue when launching older profiles (which are basically
> new profiles with some test settings tweaked and test extensions like for
> showing the error console at the bottom installed). The issue doesn't happen
> with a new profile.
> 
> These errors prevent Firefox from switching to Metro mode. Steps to
> reproduce (latest Nightly, Aurora and Beta):
> 1. Launch old profile.
> 2. Customize the toolbar and add the Windows 8 tile icon (or use the Firefox
> button on Beta).
> Actual result: Splash screen shown, closes and back to the desktop screen.
> 3. Open a command line and create a new profile.
> 4. Repeat step 2 with this profile.
> Actual result: Firefox launches in Metro mode.
> 5. Switch back to desktop mode, feel free to simply close the profile
> manager.
> 6. Launch the old profile.
> 7. Click on the Metro mode button.
> Actual result: Old profile launches in Metro mode.
> 8. Switch back to desktop mode.
> 9. Launch the profile manager and delete the new profile created in step 3.
> 10. Launch the old profile again.
> 11. Try to switch to Metro mode.
> Actual result: Splash screen shown, Firefox quits.
> 
> It seems like Firefox tries to find the metro profile from the registry
> where it isn't set or not set anymore.
> 
> The error is thrown here:
> http://mxr.mozilla.org/mozilla-central/source/toolkit/profile/
> nsToolkitProfileService.cpp#554
> 
> The difference a new profile makes seems to be the line "Default=1" in the
> profiles.ini. Before creating the new profile and after deleting it, that
> lines doesn't exist in my profiles.ini.

Based on the STR it seems like the chances of a large segment of our users encountering this is pretty small. Can you provide some better justification for tracking/blocking release on this?

Comment 16

[Benjamin Kerensa [:bkerensa]]

Feel free to renominate this when justification is provided.

Comment 17

[Sylvestre Ledru [:Sylvestre]]

We never shipped the metro support, closing!