1398136 - NS_ERROR_FAILURE in the browser console after Refresh Firefox

Status: RESOLVED FIXED

(Firefox :: Migration, defect, P3)

Description

[alexander]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170830153152

Steps to reproduce:

Open "about:support" page, click on "Refresh Firefox...". After refreshing complete open a Browser Toolbox (Ctrl + Shift + Alt + I). Go to console.


Actual results:

You will see an error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get] XULStore.js:64 (jar:file//.../omni.ja!/components/XULStore.js:64)


Expected results:

Must not be any error probably?

Comment 1

[:Gijs (he/him)]

This is because we attempt to use the XUL store early in startup and there is no profile directory. Unfortunately, the invocation is coming from C++ code so there's no JS stack to go on.

The same error appears for me when I open the profile manager on my local build. I'm trying to find a regression window for that to see if I can work out what, if anything has changed here.

We can wallpaper this by falling back to using ProfDS instead of ProfD (the "S" is for "startup"...) but really, I would prefer to understand why there is an early access there in the first place. I don't believe this used to happen.

On the whole, I doubt the error is serious. It will result in there being no persisted attributes for anything, which there wouldn't have been anyway because you just used Firefox Reset/Refresh so your profile is near enough empty (certainly the XUL store json file, which this component manages, won't be there), and because it's an error in the startup of the component, we'll just try to initialize it again the next time someone needs it, so things should still end up being stored once the component is initialized another time, after startup.

Comment 2

[:Gijs (he/him)]

It's annoying to find a regression window here because the profile manager thing seems to have been there for longer, but only surfaced recently because of bug 1395711 enabling dump logging on local builds, and our normal regression tools don't use profiles in a way where we can then reset them (they create temporary profiles, and we don't enable reset for those).

Comment 3

[Joe Hildebrand [:jhildebrand] (UTC-6)]

Marking this as P1 since we're likely to suggest a profile refresh for a good number of people that have issues transitioning to 57.

Comment 4

[:Gijs (he/him)]

(In reply to Joe Hildebrand  [:hildjj] (UTC-6) from comment #3)
> Marking this as P1 since we're likely to suggest a profile refresh for a
> good number of people that have issues transitioning to 57.

This is an error that shows up in the browser console. There should be no observable side-effects beyond it showing up there, and none have been reported so far. As I implied in comment #1, I don't think this is serious and I don't think it needs to track 57 or be a p1.

The only reason I can see to track this is if we suspect it has anything to do with the issues with refresh that were reported for 55, but I don't see anybody suggesting that it does. Matt, do you think I'm missing something here?

Comment 5

[Joe Hildebrand [:jhildebrand] (UTC-6)]

Agree with your analysis.  Unblocking from 57 and reducing to P3.

Comment 6

[Matthew N. [:MattN]]

I agree that this warning isn't a sign of major issues. I saw it while looking into the 55 Refresh issues and it didn't seem to be relevant.

The error also isn't specific to a Refresh, I think it's from showing the migrator dialog since I can reproduce it on an empty profile dir if I trigger startup migration:

/Applications/FirefoxNightly.app/Contents/MacOS/firefox --profile /tmp/new2 --migration

Comment 7

[:Gijs (he/him)]

Attachment: Bug 1398136 - use startup profile dir if necessary,

Review commit: https://reviewboard.mozilla.org/r/180620/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/180620/

Comment 8

[:Gijs (he/him)]

The attached patch fixes the migration dialog case, which is opened before ProfD is available. It does not fix the profile manager case, which is opened before there is a profile, because there isn't a reasonable fix available for that case that I can think of. But then again, you would only see the error message if dumps are enabled by default and you're monitoring stderr/stdout, and the error is now more descriptive so hopefully less surprising, and we don't actually support use of the profile manager.

Comment 9

[Matthew N. [:MattN]]

Comment on attachment 8909009 [details]
Bug 1398136 - use startup profile dir if necessary,

https://reviewboard.mozilla.org/r/180620/#review185740

Thanks.

[Surely there was a reason for having a separation of ProfD and ProfDS (the reason wasn't clear from a skim of bug 278534) and hopefully this doesn't defeat the point of the separation. I'm not sure that it matters much anymore anyways without embedding or runtime-profile-switching support.]

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0999c7162711
use startup profile dir if necessary, r=MattN

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0999c7162711