|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
59 bytes, text/x-review-board-request
|Details | Review|
1. http://www.yad2.co.il/Nadlan/ViewImage.php?CatID=2&SubCatID=5&RecordID=1625606 2. Assertion failure: aDocShell, at /mozilla/builds/nightly/mozilla/dom/base/Location.cpp:57 Assertion failure: aDocShell, at /home/worker/workspace/build/src/dom/base/Location.cpp:57 #01: nsGlobalWindow::GetLocation [mfbt/RefPtr.h:53] #02: mozilla::dom::WindowBinding::get_location [obj-firefox/dom/bindings/WindowBinding.cpp:1352] #03: mozilla::dom::WindowBinding::genericCrossOriginGetter [obj-firefox/dom/bindings/WindowBinding.cpp:15834]
We are seeing this a lot while fuzzing
That would indicate the outer nsGlobalWindow::mDocShell was nullptr, which should imply it was after nsDocShell::Destroy(). So... script can still be run after docshell destroyed?
Sure. Just have an iframe, take reference to iframe.contentWindow.location in the parent window, then remove iframe and try to use location. Or take reference to iframe.contentWindow, remove iframe, and then try to access contentWindow.location. Looks like a wrong assertion, but need to check that Location can handle null docshell.
(In reply to Olli Pettay [:smaug] from comment #3) > need to check that Location can handle null docshell. Location is using a nsWeakPtr to hold docshell, and I checked that all references to it has nullptr check on docshell and/or the queryInterface'd webNav: http://searchfox.org/mozilla-central/search?q=symbol:F_%3CT_mozilla%3A%3Adom%3A%3ALocation%3E_4&redirect=false
Assignee: nobody → sawang
Comment on attachment 8901731 [details] Bug 1368327 - Do not assert aDocShell in Location, since it's actually possible to be nullptr. https://reviewboard.mozilla.org/r/173162/#review178506
Attachment #8901731 - Flags: review?(bugs) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/294dae9f3f01 Do not assert aDocShell in Location, since it's actually possible to be nullptr. r=smaug
Status: NEW → RESOLVED
Last Resolved: 5 months ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Doubtful there's a user impact here that justifies backport consideration. Feel free to set the status for 56 back to affected and nominate for approval if you feel otherwise, though.
status-firefox55: --- → wontfix
status-firefox56: --- → wontfix
status-firefox-esr52: --- → wontfix
You need to log in before you can comment on or make changes to this bug.