Closed
Bug 947581
Opened 11 years ago
Closed 6 years ago
WindowsPrefSync.jsm errors on startup
Categories
(Firefox :: General, defect, P2)
Tracking
()
People
(Reporter: jruderman, Unassigned)
References
Details
(Whiteboard: p=0)
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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•11 years ago
|
OS: Mac OS X → Windows 7
Updated•11 years ago
|
Blocks: metroprofilesharing, metrov1backlog
Comment 1•11 years ago
|
||
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•11 years ago
|
||
Do you know if your build is metro compatible? If you took it on a win8 machine would it have metro?
Comment 3•11 years ago
|
||
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•11 years ago
|
Whiteboard: [triage]
Updated•11 years ago
|
Flags: needinfo?(jruderman)
Reporter | ||
Comment 4•11 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)
Comment 5•11 years ago
|
||
p=1 I think this is just a console spam message that we should not display
Updated•11 years ago
|
Whiteboard: [triage] → [beta28] p=0
Updated•11 years ago
|
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
Comment 6•11 years ago
|
||
Hey Stephen, can you provide a point value and I'll add it to IT#21.
Flags: needinfo?(spohl.mozilla.bugs)
Comment 7•11 years ago
|
||
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•11 years ago
|
Comment 8•11 years ago
|
||
I think it might be related to the keys not existing because the other front end wasn't launched yet.
Comment 9•11 years ago
|
||
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•11 years ago
|
Comment 10•11 years ago
|
||
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•11 years ago
|
Whiteboard: [beta28] p=2 → [beta28] [defect] p=2
Comment 11•11 years ago
|
||
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•11 years ago
|
Updated•11 years ago
|
Whiteboard: [beta28] [defect] p=0 → [release28] [defect] p=0
Updated•11 years ago
|
Whiteboard: [release28] [defect] p=0 → [release28] [defect] p=3
Comment 12•11 years ago
|
||
re-nominating for triage. This seems stuck
Whiteboard: [release28] [defect] p=3 → [triage][release28] [defect] p=3
Comment 13•11 years ago
|
||
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•11 years ago
|
Whiteboard: [triage][release28] [defect] p=3 → [triage] [defect] p=0
Updated•11 years ago
|
Whiteboard: [triage] [defect] p=0 → [defect] p=0
Comment 14•11 years ago
|
||
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)
Comment 15•11 years ago
|
||
(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?
Updated•11 years ago
|
Comment 16•11 years ago
|
||
Feel free to renominate this when justification is provided.
Updated•11 years ago
|
Whiteboard: [defect] p=0 → p=0
Comment 17•6 years ago
|
||
We never shipped the metro support, closing!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•