Closed
Bug 1247872
Opened 8 years ago
Closed 8 years ago
crash in nsILoadContext::UsePrivateBrowsing
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
RESOLVED
FIXED
mozilla47
People
(Reporter: philipp, Assigned: bzbarsky)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file, 2 obsolete files)
This bug was filed from the Socorro interface and is report bp-855b608e-5a34-4db6-8860-9a9bd2160126. ============================================================= 0 xul.dll nsILoadContext::UsePrivateBrowsing() obj-firefox/dist/include/nsILoadContext.h 1 xul.dll nsDocShell::CanAccessItem(nsIDocShellTreeItem*, nsIDocShellTreeItem*, bool) docshell/base/nsDocShell.cpp 2 xul.dll nsDocShell::CanAccessItem(nsIDocShellTreeItem*, nsIDocShellTreeItem*, bool) docshell/base/nsDocShell.cpp 3 xul.dll nsDocShell::DoFindItemWithName(wchar_t const*, nsISupports*, nsIDocShellTreeItem*, nsIDocShellTreeItem**) docshell/base/nsDocShell.cpp 4 xul.dll nsDocShell::FindItemWithName(wchar_t const*, nsISupports*, nsIDocShellTreeItem*, nsIDocShellTreeItem**) docshell/base/nsDocShell.cpp this signature seems to be a regression since 43 builds. just guessing on timing, it may be related to the landing of bug 1100154 perhaps?
Assignee | ||
Comment 1•8 years ago
|
||
Looks like it. For a document in a docshell the loadinfo should really never be null (since it's a pointer to the docshell itself), but apparently it sometimes is.... <sigh>.
Assignee: nobody → bzbarsky
Component: Private Browsing → Document Navigation
Product: Firefox → Core
Assignee | ||
Comment 2•8 years ago
|
||
Attachment #8718845 -
Flags: review?(bugs)
Comment 3•8 years ago
|
||
Comment on attachment 8718845 [details] [diff] [review] Null-check the result of GetLoadContext() when doing frame targeting, even though it really should never be null there... because apparently sometimes it is So I think we shouldn't use GetDocument at all, but just QI aAccessingItem and aAccessingItem to loadcontext. Or static cast targetDS and accessingDS to nsDocShell and use UsePrivateBrowsing() on them.
Attachment #8718845 -
Flags: review?(bugs) → review-
Assignee | ||
Comment 4•8 years ago
|
||
Attachment #8718931 -
Flags: review?(bugs)
Assignee | ||
Updated•8 years ago
|
Attachment #8718845 -
Attachment is obsolete: true
Comment 5•8 years ago
|
||
Comment on attachment 8718931 [details] [diff] [review] Updated per IRC discussion And as far as I see targetDS and accessingDS are never null here, even though there is a null check in the 'if' above. There is if (!gValidateOrigin || !aAccessingItem) { // Good to go return true; } and then if (!!targetDS != !!accessingDS) { // We must be able to convert both or neither to nsIDocShell. return false; }
Attachment #8718931 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 6•8 years ago
|
||
Well, in fairness aAccessingItem might be an nsWebBrowser. But aTargetItem certainly won't be, I would think.
Comment 7•8 years ago
|
||
oh, right. then add null check.
Assignee | ||
Comment 8•8 years ago
|
||
Sorry, one more time just to make sure we're on the same page here...
Attachment #8718978 -
Flags: review?(bugs)
Assignee | ||
Updated•8 years ago
|
Attachment #8718931 -
Attachment is obsolete: true
Comment 9•8 years ago
|
||
Comment on attachment 8718978 [details] [diff] [review] Just get our private browsing state directly off the docshells we already have instead of trying to indirect through their documents In theory someone could pass webbrowser as a param to FindChildWithName, but I think that shouldn't really return anything. WebBrowser's relevant method returns always null. align accessingDS->GetIsInBrowserElement() ||
Attachment #8718978 -
Flags: review?(bugs) → review+
Comment 11•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2cacb0f32a4c
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Reporter | ||
Comment 12•8 years ago
|
||
in 46.0b8 this crash is currently on #23 making up 0.56% of all crashes. do you think that the patch would be uplift-able to beta in terms of scope and risk?
tracking-firefox46:
--- → ?
Flags: needinfo?(bzbarsky)
Comment 14•8 years ago
|
||
I missed this last week and now we're heading into 46 beta 11. I think it may be best to let this ride with 47.
You need to log in
before you can comment on or make changes to this bug.
Description
•