Closed Bug 576518 Opened 12 years ago Closed 12 years ago
DBFile and NS _Get Special Directory fail in ns Nav History
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/2010031218 Firefox/3.5 Build Identifier: While loading http://bash.org.ru get these warnings: WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file mozilla/toolkit/components/places/src/nsNavHistory.cpp, line 540 the code is: nsresult rv = NS_GetSpecialDirectory(NS_APP_USER_PROFILE_50_DIR, getter_AddRefs(profDir)); NS_ENSURE_SUCCESS(rv, rv); in nsNavHistory::InitDBFile(PRBool aForceInit) Second warning is: WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /home/egor/harmattan_hg1/microb-engine/build-tree/mozilla/toolkit/components/places/src/nsNavHistory.cpp, line 438 the code is: rv = InitDBFile(PR_FALSE); NS_ENSURE_SUCCESS(rv, rv); in: nsNavHistory::Init() I believe that there should be no assertions in Init code always. Reproducible: Always
Seems like nav history should be failing out early on attempts to init it in the content process.
(In reply to comment #1) > Seems like nav history should be failing out early on attempts to init it in > the content process. I thought we shouldn't have been initializing history in the content process.
Also we are calling nsIWebBrowserSetup::SETUP_ALLOW_DNS_PREFETCH:, and that initializing global history because of missing "break"..
Assignee: nobody → romaxa
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #460515 - Flags: review?(bzbarsky)
and missing break coming from https://bug492196.bugzilla.mozilla.org/attachment.cgi?id=377824 ... is it expected or just bug?
Is this the same as bug 549887?
don't think so, it is about stopping history init in child process
Comment on attachment 460515 [details] [diff] [review] Stop history initialization on child process OK, I buy that, I think.
Attachment #460515 - Flags: review?(bzbarsky) → review+
Is it blocking IPC fennec?
tracking-fennec: --- → ?
is this ready to land?
tracking-fennec: ? → 2.0+
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
This broke --disable-ipc builds: it needs an #ifdef MOZ_IPC
You need to log in before you can comment on or make changes to this bug.