1313906 - DOM inspector doesn't work any more in Thunderbird

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Jorg K (CEST = GMT+2)]

+++ This bug was initially created as a clone of Bug #1279327 +++

Regression range M-C:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1561c917ee27&tochange=969c3295d3aa

Comment 1

[Jorg K (CEST = GMT+2)]

Alice, please try this in FF for us. Thanks in advance.

Comment 2

[:aceman]

Just starting DOM Inpector I get:
09:39:29.186 XML Parsing Error: no root element found
Location: chrome://global/content/globalOverlay.xul
Line Number 1, Column 1: 1 globalOverlay.xul:1:1

09:39:29.594 TypeError: document.getElementById(...) is null 1 inspector.js:72:5
	InspectorApp_initialize chrome://inspector/content/inspector.js:72:5

You can File->Inspect a Chrome document, but then the "Find a node by clicking on it" icon does not work.

Comment 3

[Richard Marti (:Paenglab)]

Attachment: noglobal.patch

This is a regression from bug 1312143. I had this patch since then but forgot it. Sorry :(

I hope Ian is the correct reviewer for DOMi.

Comment 4

[Jorg K (CEST = GMT+2)]

Backing out https://hg.mozilla.org/mozilla-central/rev/a1ea2703d9e8 from bug 1203813 locally does NOT fix this issue. So Alice, can you please find the regression here.

On the console I see:
Error getting service: @mozilla.org/inspector/flasher;1, inIFlasher
TypeError: Components.classes[aURL] is undefinedJavaScript error: chrome://inspector/content/inspector.js, line 72: TypeError: document.getElementById(...) is null

Comment 5

[Jorg K (CEST = GMT+2)]

Ignore comment #4, wires crossed with comment #3.

Comment 6

[Jorg K (CEST = GMT+2)]

How do you build the DOMi? I added 
  ac_add_options --enable-extensions=default,inspector
to my TB .mozconfig (following: http://asurkov.blogspot.de/2013/02/build-dom-inspector.html) but that didn't build it.

Comment 7

[Richard Marti (:Paenglab)]

I have ac_add_options --enable-extensions="inspector" and it builds. I think the "default" isn't needed as it works without it here. You could also only monkey patch the file directly in the extension folder of your profile.

Comment 8

[Ian Neal]

Comment on attachment 8805832 [details] [diff] [review]
noglobal.patch

One of the things loading the overlay globalOverlay.xul did was to pull in globalOverlay.js
This seems fine for SeaMonkey as their utilityOverlay.xul loads globalOverlay.js thus dealing with things like cmd_quit, but does Thunderbird load it in some other way?

Comment 9

[aleth [:aleth]]

Is the DOM inspector still maintained? Would it be better to stop shipping it altogether now the devtools inspector is included?

Comment 10

[Jorg K (CEST = GMT+2)]

It's an add-on for TB. And I like to use it. What do you mean by "stop shipping it" since we don't ship it in the first place. What am I missing?

Comment 11

[aleth [:aleth]]

(In reply to Jorg K (GMT+1) from comment #10)
> It's an add-on for TB. And I like to use it. What do you mean by "stop
> shipping it" since we don't ship it in the first place. What am I missing?

Ah, you're right, my bad. As we pull it with every client.py, I'd completely forgotten it was an addon I had once installed manually ;)

Comment 12

[Jorg K (CEST = GMT+2)]

(In reply to Ian Neal from comment #8)
> ... to pull in globalOverlay.js ..., ... does
> Thunderbird load it in some other way?
https://dxr.mozilla.org/comm-central/search?q=globalOverlay.js&redirect=false

We seem to load it left, right and centre. What am I missing?

Comment 13

[Ian Neal]

(In reply to Jorg K (GMT+1) from comment #12)
> (In reply to Ian Neal from comment #8)
> > ... to pull in globalOverlay.js ..., ... does
> > Thunderbird load it in some other way?
> https://dxr.mozilla.org/comm-central/search?q=globalOverlay.js&redirect=false
> 
> We seem to load it left, right and centre. What am I missing?

Just asking whether any dependencies on globalOverlay.js have been checked when using DOMi with TB.

Comment 14

[Richard Marti (:Paenglab)]

(In reply to Ian Neal from comment #8)
> Comment on attachment 8805832 [details] [diff] [review]
> noglobal.patch
> 
> One of the things loading the overlay globalOverlay.xul did was to pull in
> globalOverlay.js
> This seems fine for SeaMonkey as their utilityOverlay.xul loads
> globalOverlay.js thus dealing with things like cmd_quit, but does
> Thunderbird load it in some other way?

Like Jörg already replied it is loaded on a lot of places. Using DOMi on a daily base it is working for me like before. At least where I am using it.

Comment 15

[Richard Marti (:Paenglab)]

(In reply to aleth [:aleth] from comment #9)
> Is the DOM inspector still maintained? Would it be better to stop shipping
> it altogether now the devtools inspector is included?

I hope not. I like it a lot more than the devtools inspector. The devtools inspector for example is showing too much in DOM tree which makes it hard to find the correct entry and to see the parent/childs etc.

Comment 16

[Richard Marti (:Paenglab)]

https://hg.mozilla.org/dom-inspector/rev/f18146654a5a21208736e17cd02e3cdd0202827f

Comment 17

[:aceman]

I also like DOM Inspector and rely on it daily. But is not working fully for some time, e.g. I can't any longer click on elements to inspect and it is producing errors in the console. It probably needs a new release accommodating the recent changes in m-c.

Comment 18

[Philip Chee]

(In reply to :aceman from comment #17)
> I also like DOM Inspector and rely on it daily. But is not working fully for
> some time, e.g. I can't any longer click on elements to inspect and it is
> producing errors in the console. It probably needs a new release
> accommodating the recent changes in m-c.

Care to file bugs with the error messages? Patches would also be nice.

Comment 19

[:aceman]

> Care to file bugs with the error messages? Patches would also be nice.

It seems the current trunk is better, clicking element works and does not reference STEEL.
There is just no release containing these fixes.