Closed Bug 460680 Opened 16 years ago Closed 16 years ago

WARNING: NS_ENSURE_TRUE(presShell) failed

Categories

(Core :: DOM: Navigation, defect)

x86
Linux
defect
Not set
minor

Tracking

()

RESOLVED FIXED
mozilla1.9.1b2

People

(Reporter: MatsPalmgren_bugz, Assigned: MatsPalmgren_bugz)

Details

Attachments

(2 files, 1 obsolete file)

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?
Attached file Stack for the warning
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.
Oh, and the point is that there is no reason whatsoever why a docshell should particularly have a current presshell or prescontext.
You're right, it's the sidebar.
Attached patch Patch rev. 1 (obsolete) — Splinter Review
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 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+
Attached patch Patch rev. 2Splinter Review
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
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
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.

Attachment

General

Created:
Updated:
Size: