click-select-node no longer works; tree view not updated on URL loads

RESOLVED FIXED

Status

Other Applications
DOM Inspector
--
major
RESOLVED FIXED
16 years ago
11 years ago

People

(Reporter: bz, Assigned: Håkan Waara)

Tracking

({regression})

Trunk
x86
Linux
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

This is a regression from the fix for bug 156072.  Backing out the dom.js change
fixes it.

There are two problems:

1)  The "Find a node to inspect by clicking on it" functionality does not work
2)  Typing a url in the urlbar (in inspector) and hitting enter does not update
    the top-left DOM tree view immediately.  It ends up waiting on some event or
    something...

There are no errors in the JS console.
Keywords: mozilla1.1, regression
Created attachment 92364 [details]
screenshot of weird behaviour

another strange thing is that clicking the document node opens a DOM-inspector
in the "nodeinfo-pane". Kind'a hard to describe, have a look at the screenshot
jst says this may be due to some code somewhere QIing to nsIContent; documents
implement nsIDOMNode but not nsIContent....
*** Bug 159079 has been marked as a duplicate of this bug. ***
Created attachment 92560 [details] [diff] [review]
This is the tip of the iceberg

So.... we need to call selectElementInTree on the right thing in
setInitialSelection().	This fixes the "can't click-select" and "view not
updated" issues.  _However_, when this is done the problem sicking noticed
kicks in....  The live tree is on the _right_, not on the left.  That's not so
great.	No idea yet why that's happening.

A further issue is that even with this patch, if the #document node's twisty is
collapsed and then we try to do click-to-select things break.  The reason is
that inDeepTreeWalker::ParentNode effectively skips over the #document node and
runs up into XUL while looking for the tree root.  This could be fixed by
either hacking ParentNode() to somehow recognize that it has come to the root
of the view _or_ by showing #document nodes as children of iframes and then
having ParentNode() only jump for a _document_, not a documentElement.	So the
display would be something like:

#document
  <?pi?>
  HTML
    BODY
      IFRAME
	#document
	  <?pi?>
	  HTML
	    BODY

Thoughts on that?

We need to either fix this by a day or two from now or back out the dom.js
changes from bug 156072; shipping 1.1 like this is unacceptable.
Created attachment 92800 [details] [diff] [review]
backout patch
Attachment #92560 - Attachment is obsolete: true
Comment on attachment 92800 [details] [diff] [review]
backout patch

this has r=caillon, rs=jst
Attachment #92800 - Flags: superreview+
Attachment #92800 - Flags: review+

Comment 7

16 years ago
Comment on attachment 92800 [details] [diff] [review]
backout patch

a=asa (on behalf of drivers) for checkin to 1.1
Attachment #92800 - Flags: approval+
fixed
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Product: Core → Other Applications
QA Contact: timeless → dom-inspector
You need to log in before you can comment on or make changes to this bug.