1838879 - Warning spam from GetProfileStartupDir()

Status: RESOLVED FIXED

(Core :: XPCOM, task)

Description

[Andrew McCreight [:mccr8]]

3824 WARNING: NS_ENSURE_TRUE(mProfileDir) failed: file toolkit/xre/nsXREDirProvider.cpp:1162
3824 WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file toolkit/xre/nsXREDirProvider.cpp:467

The first is in nsXREDirProvider::GetProfileStartupDir(), presumably from somebody calling it in a child process.

The second one looks like it is here, for NS_APP_USER_CHROME_DIR:

    rv = GetProfileStartupDir(getter_AddRefs(file));
    NS_ENSURE_SUCCESS(rv, rv);

The warning counts are identical, so that makes sense.

Comment 1

[Andrew McCreight [:mccr8]]

Attachment: Bug 1838879 - Centralize warning for nsXREDirProvider::mProfileDir.

nsXREDirProvider::mProfileDir will never be defined in a non-main process, so
adding a warning if we're missing one in that case just adds noise to the logs.

There was a lot of redundant ENSURE warning in code that ultimately depended
on mProfileDir, so this code rearranges things so that it all goes through
GetProfileStartupDir, then makes it so that we warn there if appropriate,
and do not warn anywhere else.

Looking back at the commit that added the comment about the
profile-after-change notification, this seems to be referring to a check on some
field mProfileNotified which no longer exists. Additionally, the component and
XPT registrations seem to be referring to NS_XPCOM_COMPONENT_REGISTRY_FILE and
NS_XPCOM_XPTI_REGISTRY_FILE, which also no longer exist. Therefore, I have
removed the comment and added a new one about the oddity of this particular
case.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d2919829e4eb
Centralize warning for nsXREDirProvider::mProfileDir. r=xpcom-reviewers,nika

Comment 3

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/d2919829e4eb