Closed
Bug 460680
Opened 16 years ago
Closed 16 years ago
WARNING: NS_ENSURE_TRUE(presShell) failed
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9.1b2
People
(Reporter: MatsPalmgren_bugz, Assigned: MatsPalmgren_bugz)
Details
Attachments
(2 files, 1 obsolete file)
6.22 KB,
text/plain
|
Details | |
11.85 KB,
patch
|
Details | Diff | Splinter Review |
STEPS TO REPRODUCE 1. start Firefox debug build on any URL 2. press Alt+LeftArrow ACTUAL RESULTS WARNING: NS_ENSURE_TRUE(presShell) failed: file /usr/moz/hg2/docshell/base/nsDocShell.cpp, line 3923 I poked around a bit in a debugger and found that it's a chrome docshell, with a document with uri "about:blank" and that presContext/Shell are both null. Dumping the docshell tree: DS 0xf9bff8 Type Chrome EM 0x6e0210 "chrome://browser/content/browser.xul" DS 0x11e6aa8 Type Chrome EM (nil) "about:blank" DS 0x143fcd8 Type Content EM 0x1d1a320 "http://www.google.se/" It's 0x11e6aa8 that causes the warning - what is this docshell for?
Assignee | ||
Comment 1•16 years ago
|
||
Comment 2•16 years ago
|
||
If you look at the docshell's window's frameElement, is it display:none? I'd bet it is, and that this is the sidebar iframe or some such nonsense. In any case, we could not warn here: should just null-check and say no if there is no presshell or something. Or even keep returning error without warning.
Comment 3•16 years ago
|
||
Oh, and the point is that there is no reason whatsoever why a docshell should particularly have a current presshell or prescontext.
Assignee | ||
Comment 4•16 years ago
|
||
You're right, it's the sidebar.
Assignee | ||
Comment 5•16 years ago
|
||
In ESM: cleanup and improve the PrintDocTree() debug utility function - getting the document through the content viewer instead of the shell, printing its URI, not assumning non-null pres context/shell etc. Fix remaining compile warnings. In nsDocShell: Return silently when no pres shell. Cleanup the code a bit by initializing *aVisibility = PR_FALSE at the top. I also added "parent" to the NS_NOTREACHED there since I assume that's what it wants to point out, i.e. 'this' has a pres shell but one our parent docshells doesn't. Fix a compile warning.
Assignee: nobody → mats.palmgren
Attachment #343837 -
Flags: superreview?(bzbarsky)
Attachment #343837 -
Flags: review?(bzbarsky)
Comment 6•16 years ago
|
||
Comment on attachment 343837 [details] [diff] [review] Patch rev. 1 >+++ b/content/events/src/nsEventStateManager.cpp >+PrintDocTree(nsIDocShellTreeNode* aParentNode, int aLevel) This should take an nsIDocShellTreeItem (since all treeitems are treenodes and you can therefore drop a bunch of QIs). >+PrintDocTreeAll(nsIDocShellTreeItem* aItem) This seems to be unused. r+sr=bzbarsky with the unused bit explained and the node/item stuff fixed.
Attachment #343837 -
Flags: superreview?(bzbarsky)
Attachment #343837 -
Flags: superreview+
Attachment #343837 -
Flags: review?(bzbarsky)
Attachment #343837 -
Flags: review+
Assignee | ||
Comment 7•16 years ago
|
||
Ok, I changed the type to nsIDocShellTreeItem. Neither function is called from elsewhere in the code, even when DEBUG_DOCSHELL_FOCUS is defined. The intended use is from a debugger or if one wants to add calls while investigating some bug like I did here.
Attachment #343837 -
Attachment is obsolete: true
Assignee | ||
Comment 8•16 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/b4dce4c66f59 (There are plenty of mochitests that triggered the warning so no special regression test is needed) -> FIXED
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2
Comment 9•16 years ago
|
||
Guys, there is a similar effect when embedding Mozilla into custom application. I think, maybe #ifdef DEBUG_DOCSHELL_FOCUS can be changed to something different?
You need to log in
before you can comment on or make changes to this bug.
Description
•