User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Build Identifier: When inspect dom inspector and change the tree view, the title of window have repeated name. Reproducible: Always Steps to Reproduce: 1. Open dom inspector. 2. Inspect chrome document -> dom inspector. 3. Change DOM Nodes to Accessible tree.

Is that in trunk builds as well? (The new badgerbadgerbadger...)

It is in trunk.

confirm

I think this patch decide this problem.

you might have a better chance of getting a review for timeless or db48x right now - I'm swamped.

Comment on attachment 286658 [details] [diff] [review] patch this seems wrong. isn't the correct test: aEvent.subject == window steps: 1. open dom inspector 2. open dom inspector 3. use 1 to inspect 2 4. use 2 to inspect 1

Right, thanks.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4) Works fine. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090228 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/f7f62131998d +http://hg.mozilla.org/comm-central/rev/7ea34ef19dc4) Has this bug. The bug is that |document.documentElement.getAttribute("title")| "now" returns the current (full) title instead of "DOM Inspector" only. I don't know when/why that behavior changed.

(In reply to comment #9) > The bug is that |document.documentElement.getAttribute("title")| "now" returns > the current (full) title instead of "DOM Inspector" only. Was DOMi relying on a bug ? Or is it Core which regressed ?

I think DOMI was relying on a bug.

(In reply to comment #11) > I think DOMI was relying on a bug. I would think so too. *** [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090228 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/f7f62131998d +http://hg.mozilla.org/comm-central/rev/7ea34ef19dc4) This fixes the general case :-) It does not fix comment 0 case of self inspecting :-| I'm not sure what to think about comment 7... (helpwanted on these.)

Comment on attachment 366091 [details] [diff] [review] (Bv1) Reuse the initial title [Checkin: Comment 13] http://hg.mozilla.org/dom-inspector/rev/3a50d3e1506c

The original bug still exists. It's because the title setting occurs on subjectChange, which doesn't happen only when a new document is inspected; it happens for every viewer change. (It's part of the |subject| setter, which has to be called after viewer initialization for obvious reasons.) Since the title-setting is treating the subjectChange event as if it represents a change in the inspected document, we should probably just make a "documentInspect" event that does signify this.

(In reply to comment #14) > we should probably just make a "documentInspect" event That's kind of silly, actually. Although this is pretty straightforward to fix, I'm inclined to just say "Don't use DOM Inspector to inspect its own document (or its viewers')." Use it to inspect another DOM Inspector window, sure, but its own window? I'd go so far as to say we should probably exclude them from the Inspect Chrome Document menupopup (and its browser pane's document from the Content menupopup). They sort of just clutter things when you're not wanting it to inspect itself. Plus, then you don't run into issues like what happens when you're inspecting the object viewer's document (or the inspector window's document with the viewer's subtree opened while you're poking at it), and you select a node which the current viewer doesn't support, so it flips over to a different one and messes up the visible nodes in the left pane.

(In reply to Colby Russell :crussell from comment #14) > The original bug still exists. It's because the title setting occurs on > subjectChange, which doesn't happen only when a new document is inspected; > it happens for every viewer change. (It's part of the |subject| setter, > which has to be called after viewer initialization for obvious reasons.) > > Since the title-setting is treating the subjectChange event as if it > represents a change in the inspected document, we should probably just make > a "documentInspect" event that does signify this. Quite old, has a patch checked in, if there is more to do we should probably open a new bug.