251274 - [FIX]Error: [Exception... "Node was not found" code: "8" nsresult: "0x80530008 (NS_ERROR_DOM_NOT_FOUND_ERR)" location: "chrome://inspector/content/inspector.xml Line: 684"]

Status: RESOLVED FIXED

(Other Applications :: DOM Inspector, defect, P1)

Description

[timeless]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520

Steps:
1. open domi
2. view>browser
3. chrome://navigator/content
4. fullscreen
5. widget view switch to style sheet
6. widget view switch to Javascript(sp) object

Error: [Exception... "Node was not found"  code: "8" nsresult: "0x80530008
(NS_ERROR_DOM_NOT_FOUND_ERR)"  location:
"chrome://inspector/content/inspector.xml Line: 684"]
Source File: chrome://inspector/content/inspector.xml
Line: 684

reproducable: once confused, the domi will remain confused.

Comment 1

[[e-mail]]

Something weird seems to be happening, but I don't understand it, so CCing a
bunch of DOM folks to see if they can chip in.

First, turn off JavaScript in the browser, load chrome://inspector/content/ and
then press Ctrl+Shift+I to inspect it; if you look the window should have three
popupset children, the third (ppsViewerPopupset) with child ppViewerContext-dom.

Now open a third DOM inspector to inspect the second DOM inspector. Note that
the ppViewContext-dom is no longer a child of ppsViewerPopupset. JavaScript has
actually moved it in the DOM to a child of an XBL-anonymous node.

Now switch the second DOM inspector to "Stylesheets" view. Note that the
ppViewContext-dom is now an anonymous child of ppsViewerPopupset! However the
JavaScript still believes that it's still the child of the XBL-anonymous node.

Comment 2

[Brian Polidoro]

In my opinion this really hurts the use of the DOM inspector.  As soon as you
make a second change to which DOM Inspector information type you are looking at:
(DOM nodes, Javascript object, or stylesheets), you can't do much else because
the left listview becomes and remains blank.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050801
Firefox/1.0+ ID:2005080106

Comment 3

[Chris Beard]

-ing but will accept a patch if it is ready in time.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

This just makes sure that this.mContextMenu is maintained properly.  As it was,
we ended up thinking we had a context menu when we really didn't.

Comment 5

[[e-mail]]

Comment on attachment 193251 [details] [diff] [review]
Fix

Doh!

What confused me is that the menu is contextual but not a context menu in the
generally accepted sense.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 193251 [details] [diff] [review]
Fix

Requesting 1.8b4 approval for this very simple and safe DOM inspector patch.

Comment 7

[Chris Beard]

Comment on attachment 193251 [details] [diff] [review]
Fix

a=cbeard

Comment 8

[Boris Zbarsky [:bzbarsky]]

Fixed, trunk and branch (for 1.8b4 and 1.9a1).