WindowsPrefSync.jsm errors on startup

NEW
Unassigned

Status

()

Firefox
General
P2
normal
4 years ago
2 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

Trunk
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox28 affected, firefox29 affected, firefox30- affected)

Details

(Whiteboard: p=0)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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]
(Reporter)

Updated

4 years ago
OS: Mac OS X → Windows 7
Blocks: 924860, 838081
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?
Do you know if your build is metro compatible? If you took it on a win8 machine would it have metro?
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?

Updated

4 years ago
Whiteboard: [triage]
Flags: needinfo?(jruderman)
(Reporter)

Comment 4

4 years ago
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.
Flags: needinfo?(jruderman)
p=1 I think this is just a console spam message that we should not display

Updated

4 years ago
Whiteboard: [triage] → [beta28] p=0
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
Hey Stephen, can you provide a point value and I'll add it to IT#21.
Flags: needinfo?(spohl.mozilla.bugs)
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.
Flags: needinfo?(spohl.mozilla.bugs)
Whiteboard: [beta28] p=0 → [beta28] p=2

Updated

4 years ago
Blocks: 947326
No longer blocks: 838081
Priority: -- → P2
QA Contact: jbecerra
I think it might be related to the keys not existing because the other front end wasn't launched yet.
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!
Flags: needinfo?(jruderman)

Updated

4 years ago
Blocks: 955892
No longer blocks: 947326
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

Updated

4 years ago
Whiteboard: [beta28] p=2 → [beta28] [defect] p=2
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.
Assignee: spohl.mozilla.bugs → nobody
Whiteboard: [beta28] [defect] p=2 → [beta28] [defect] p=0

Updated

4 years ago
Blocks: 838081
No longer blocks: 955892
Status: ASSIGNED → NEW
QA Contact: jbecerra

Updated

4 years ago
Whiteboard: [beta28] [defect] p=0 → [release28] [defect] p=0

Updated

4 years ago
Whiteboard: [release28] [defect] p=0 → [release28] [defect] p=3
re-nominating for triage. This seems stuck
Whiteboard: [release28] [defect] p=3 → [triage][release28] [defect] p=3
Created attachment 8366231 [details]
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.

Updated

4 years ago
Whiteboard: [triage][release28] [defect] p=3 → [triage] [defect] p=0

Updated

4 years ago
Blocks: 861680
No longer blocks: 838081
Whiteboard: [triage] [defect] p=0 → [defect] p=0
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.
status-firefox28: --- → affected
status-firefox29: --- → affected
status-firefox30: --- → affected
tracking-firefox30: --- → ?
Flags: needinfo?(jruderman)
(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?
tracking-firefox30: ? → -
Feel free to renominate this when justification is provided.

Updated

4 years ago
Whiteboard: [defect] p=0 → p=0
You need to log in before you can comment on or make changes to this bug.