254031 - DOM inspector from addons.mozilla.org needs to work on thunderbird

Status: VERIFIED FIXED

(Thunderbird :: General, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

Current nightlies and versions 0.7.x don't contain the DOM inspector anymore.
Searching on update.mozilla.org also doesn't show the extension. Why this
extension was removed or was it forgotten during the update of the new extension
manager?

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

Asking for blocking aviary1.0PR?

Comment 2

[Nickolay_Ponomarev]

I miss it too. IMO, it should be an extension, but as far as I understand,
current implementation of EM doesn't allow some of the features
DOMi-as-an-extension needs (such as installing a dll into application folder and
copying res\ contents automatically. I will probably file those issues as
separate bugs)

As a workaround see http://forums.mozillazine.org/viewtopic.php?p=702520#702520

Comment 3

[CatThief]

I would like to see this returned, too... packaged with Tb.

Comment 4

[chris hofmann]

available as an extension.  trying to keep tbird download small and simple.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

(In reply to comment #4)
> available as an extension.  trying to keep tbird download small and simple.

Where can i download this extension? Looking at
http://update.mozilla.org/extensions/showlist.php?type=E&application=thunderbird&numpg=
doesn't show me any extensions which looks like DOMi. The argument for a small
download is nutty, sorry. DOMi is a part which should be included as default and
also to offer the same features as Firefox.

Comment 6

[Asaf Romano (gone)]

(In reply to comment #4)
> available as an extension

No, it isn't

Comment 7

[Rob North]

Inspector for Thunderbird can be found at the following URL.
http://downloads.mozdev.org/cdn/insptb.xpi
See also:
http://kb.mozillazine.org/index.phtml?title=DOM_Inspector

This file should be on the main Thunderbird download page.
Also, it Should be maintained by the standard Mozilla development process.
Why?
Because you don't want any old geezer passing off their code as a
Mozilla-developed extension.

Comment 8

[Doug Wright]

I thought it was part of the .ZIP for those that wanted it?

Comment 9

[Pascal Chevrel (relman team) -> :pascalc]

it's not part of the zip package and the hacked version indicated in comment #7
do not work with Thunderbird 1.0

DOM inspector is unfortunately no more, no wonder there arre so few extensions
for thunderbird...

Comment 10

[Nickolay_Ponomarev]

DOMi works with 1.0, you'll just need to bump its maxversion in install.rdf, iirc.
I wonder if it should be moved to Other apps:DOMi?

Comment 11

[Asa Dotzler [:asa]]

I can't see why we'd hold up shipping Thunderbird for this. For Firefox, I could
see, since web developers might want it. 

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

Asa: as a Thunderbird extension developer, life without DOMi is pretty painful.
 I don't actually think it's especially important that this should literally
hold 1.1 from shipping, but chofmann said that setting the blocking1.1 flag was
the only way to get something on the 1.1 radar.  And I do think that it's
important that DOMi XPIs are made available around the time 1.1 ships.  The fact
that such XPIs were never made available for 1.0(.x) at all seems like a real
failure to me.

Comment 13

[Scott MacGregor]

we won't be adding dom inspector to our end user oriented releases. For devs, it
builds as a build extension by adding inspector to the list of extension flags.
Interested folks can then publish those extension components as a stand alone
extension for the release like folks did with 1.0.

Comment 14

[Mike Shaver (:shaver emeritus)]

1.1 isn't only a user release, and one of the reasons that there is such a large
and energetic developer community for Firefox is that you don't have to build a
tree (quite an undertaking) in order to make a pretty great extension, and debug it.

mozilla.org should absolutely be making thunderbird-compatible DOM inspector
packages available from somewhere reliable, for all the platforms we ship.  I
think we should do the same with Venkman, too, but it's rotted so far that it
doesn't work on the trunk.

"For 1.0", there is still nowhere I can find a working DOMi package that
installs against 1.0.2 for many platforms, and even the ones that I can find
_something_ for (win32, Linux/x86, OS X) require me to hack the install.rdf in
order to coerce it to install.  Not something we want to be telling our
developer community to do casually, IMO.  Maybe I'm not looking in the right
place, in which case I'd be more than happy to be pointed at such a package.  We
had the same "it's available in an extension" claim made in August, but nobody
was able to point out where to find it.

I don't buy into the belief that we should spare no expense to accomodate
third-party developers, but I _do_ believe that we gain tremendously from having
people experiment on top of our mail platform, such as it is, and giving us
things like Forumzilla and Smartfiler (I think that's what it's called).

Without DOMi, there is basically no way to figure out what's what in the maze of
overlays and jar.mn-overrides that make up the Thunderbird chrome.  If DOMi is
not available as part of the "Advanced" install choices, then we need to have
building of an installable XPI and pushing it to the FTP servers become part of
the build automation so that it's there for every release.

How much download size do we lose if we just throw the DOMi XPI into the
installer, and put it in some "Extras" folder in the install directory?  I can
understand not wanting it in the Tools menu by default, I guess, though with the
JS console there I'm not sure exactly what the objection is.

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

I think Mike really hit the nail on the head here:

> I don't buy into the belief that we should spare no expense to accomodate
> third-party developers, but I _do_ believe that we gain tremendously from
> having people experiment on top of our mail platform

This seems like really low-hanging fruit as far as encouraging development goes,
and the real issue here is not that DOMi doesn't come with Thunderbird, but that
there's no easy way to get it today without either building a full tree or
mucking around inside rdf files.  Is it an unreasonable burden to commit to, if
nothing else, making DOMi available on addons.mozilla.org around the time that
1.1 ships?

Comment 16

[chris hofmann]

could we get Chris Neale who made an XPI package for Thunderbird 1.0 to do the
same for 1.1 and get that hosted on umo, or work on build patches that would
keep an addon package in sync?

Comment 17

[Chris Neale]

I've checked in a new insptb-trunk.xpi into mozdev cvs ... may hit the mirrors
in a few hours :

http://downloads.mozdev.org/cdn/insptb-trunk.xpi

Quickly tested on http://ftp.mozilla.org/pub/mozilla.org/thunderbird/
nightly/2005-05-02-10-trunk/Thunderbird-powerpc-apple-darwin7.8.0.dmg

Inspector Platform specific components from these Firefox nightlies :

Windows / Mac OS X : 2005-05-02-07-trunk
Linux : 2005-05-02-08-trunk

Please break.

ZZzzZz time.

Comment 18

[Chris Neale]

(In reply to comment #16)
> could we get Chris Neale who made an XPI package for Thunderbird 1.0 to do the
> same for 1.1 and get that hosted on umo, or work on build patches that would
> keep an addon package in sync?

What would the latter entail ?

Comment 19

[Brian King [:kinger]]

(In reply to comment #17)
> I've checked in a new insptb-trunk.xpi into mozdev cvs ... may hit the mirrors
> in a few hours :
> 
> http://downloads.mozdev.org/cdn/insptb-trunk.xpi

Appears to work fine.

Comment 20

[Dan Mosedale (:dmosedale, :dmose)]

It appears that bsmedberg now has this building (as an extension and potentially
an XPI too) and working in the main Mozilla CVS as well.  So it would seem that
the final thing to do is somehow tweak the release process such that with each
release, the appropriate XPI gets pushed to addons.mozilla.org.  chase/mscott:
what is this likely to entail?

Comment 21

[Benjamin Smedberg]

I can very easily have the build system make dist/inspector.xpi (or whatever
name seems appropriate), then the build machines will need to find that XPI and
ship it to the FTP server. The UMO-updating work will need to happen by hand at
release time. Note that it doesn't matter whether it is a Firefox build machine
or a Thunderbird build machine: it should produce the exact same result.
Inspector is, however, a platform-specific extension and we therefore need to
ship a different XPI for each platform.

Comment 22

[Chris Neale]

Or ship one with all the binaries [as comment 17], unless MoFo are expecting to
support more than Win/Lin/Mac ?

Comment 23

[Benjamin Smedberg]

Creating a multi-platform XPI would need manual processing of data from
different build machines, and would be bloaty to boot. Firefox is already
shipping the DOMI extension by default (or based on the custom installer pref),
so we would end up with mismatched extensions and such which doesn't sound good
to me.

Comment 24

[Dave Miller [:justdave]]

Wanted to make a really minor css tweak in my Thunderbird to make my life
easier, but I'm having a heck of a time figuring out the classname or ids to
tweak, and it would make my life a lot easier if this were available. :)  (only
saying anything at all since it's been a few months since this has been touched).

Comment 25

[orestis]

I want to vote on this too. It's very hard to develop extensions for thunderbird without it.

Comment 26

[Pierre-André Galmes]

I also want to vote for adding the DOM inspector to Thunderbird, it is a very convenient for development

Comment 27

[Scott MacGregor]

I've added a windows extension of DOM Inspector which is compatible with Thunderbird 1.5 to addons.mozilla.org. I'll post the URL once it is accepted by the  addon editors.

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

(In reply to comment #27)
> I've added a windows extension of DOM Inspector which is compatible with
> Thunderbird 1.5 to addons.mozilla.org. I'll post the URL once it is accepted by
> the  addon editors.

Scott, why it's only a windows version? Do you have used platform specific code? A lot of us using Linux and would also be happy to have this extension installed. Do you see a chance to get it working for Linux without to offer too much work? I know you are in the last steps of Tb1.5.

Comment 29

[Scott MacGregor]

The editors approved my extension:

https://addons.mozilla.org/extensions/moreinfo.php?id=1806&application=thunderbird

Comment 30

[Dave Miller [:justdave]]

(In reply to comment #28)
> Scott, why it's only a windows version?

I can't vouch for Linux, but I just tried building what's in CVS on the 1.8 branch right now, and it doesn't work on Mac OS X.  You get lots of XUL error garbage on the bottom half of the window, and it doesn't actually function.

Comment 31

[Mike Cowperthwaite]

Thanks, Scott.  It works fine.

Is there any way that, when re-enabling the extension in 1.5 after running a trunk build that disabled it, I don't have to RE-re-start in order to use it?

Comment 32

[Dave Miller [:justdave]]

(In reply to comment #31)
> Is there any way that, when re-enabling the extension in 1.5 after running a
> trunk build that disabled it, I don't have to RE-re-start in order to use it?

That sounds like bug 322702

Comment 33

[Ilja Sekler]

(In reply to comment #30)

Linux Thunderbird CVS 1.8 branch build with DOM inspector (checkout start: Sa Jan 7 14:51:56 CET 2006): the inspector does work but produces a XUL warning and 2 errors every time it starts:

Warning: Failed to load overlay from chrome://browser/content/baseMenuOverlay.xul.
Source File: chrome://inspector/content/inspector.xul
Line: 0

Error: undefined entity
Source File: chrome://communicator/content/tasksOverlay.xul
Line: 17, Column: 3
Source Code:
  <key id="key_navigator"    key="&navigatorCmd.commandkey;"   command="Tasks:Navigator" modifiers="accel"/>--^

Error: undefined entity
Source File: chrome://editor/content/editorTasksOverlay.xul
Line: 59, Column: 5
Source Code:
    <key id="key_editor" key="&editorCmd.commandkey;" command="Tasks:Editor" modifiers="accel"/>----^

The entry

sourcetext {
 display: none !important;
}

in userChrome.css masks the problem, but it isn't of course a solution.

Do you get the same errors on Mac OS X?

Comment 34

[Scott MacGregor]

I posted a Mac version on addons a couple days ago. I'll post a URL once it gets approved by the editors.

Comment 35

[Scott MacGregor]

justdave is seeing: https://bugzilla.mozilla.org/show_bug.cgi?id=295711#c25

which i've been working around in my version of the extension on addons.

Comment 36

[AKIHIRO Misaki (a.k.a Kuden)]

Attachment: Japanese Language pack

Scott, A lot of Japanese people want also to use DOM Inspector on Thunderbird. 
Could you add a Japanese locale?
I had inquired of Mozilla Japan. The language resource made of Mozilla Japan is possible to redistribution under the MPL/LGPL/GPL tri-license.

Comment 37

[Scott MacGregor]

The addon reviewers just approved my Mac OS X extension for dom inspector:

https://addons.mozilla.org/extensions/moreinfo.php?application=thunderbird&numpg=10&id=1837

Comment 38

[Mike Cowperthwaite]

The 'homepage' listed in the install.rdf points to
  http://www.mozilla.org/projects/inspector/
instead of
  https://addons.mozilla.org/firefox/1806/

That's going to break auto-updates, right?  Even if the code doesn't need to change for post-1.5 builds, the install.rdf needs to be accessible when the version number gets bumped.

Is there any reason I shouldn't tweak my local copy of install.rdf to show compatibility with 3.0?

Comment 39

[Benjamin Smedberg]

Homepage has nothing to do with updates.

Comment 40

[Magnus Melin [:mkmelin] (away until Aug 10)]

Any plans of making the DOM Inspector available for linux? 

Comment 41

[Scott MacGregor]

the linux version is on addons. Maybe it's still in the review queue if it hasn't shown up yet. 

Comment 42

[Mike Cowperthwaite]

Could we get the "supported versions" updated so this will enable with the 2a1 builds?  I've had some success tweaking it locally and starting offline, but it's not staying enabled consistently.  (It doesn't work at all for 3a1.)

Comment 43

[Mike Cowperthwaite]

(In reply to comment #42)
> I've had some success tweaking it locally and starting offline, but
> it's not staying enabled consistently.  (It doesn't work at all for 3a1.)

I figured out why I had a problem here, but now how the problem came about.
My local install.rdf file had the |RDF:about="rdf:#$hHg.L1"| tag located after the |RDF:about="urn:mozilla:install-manifest"| tag, which references the 
former.  When I reordered the tags, the |maxVersion=2.0.*| field gave the desired result.  Robert, is that expected behavior?

Scott, it still would be good to update install.rdf online so that users of version 2 can keep using DOMi.

Comment 44

[Robert Strong (they/them - no direct email)]

Mike, it won't install at all if the install.rdf is incorrect and I highly doubt if it caused the problem. Also, with a maxVersion of 2.0.* it will never work with 3.0a1.

btw: you can set extensions.checkCompatibility=false in about:config to disable compatibility checking but doing so prevents disabling of extensions that could cause problems due to being incompatible.

Comment 45

[Mike Cowperthwaite]

(In reply to comment #44)
> Mike, it won't install at all if the install.rdf is incorrect and I highly
> doubt if it caused the problem.

The install.rdf that I was talking about had been manually tweaked by me to change maxVersion.  The sequence, as I remember it, was:
  install (maxversion = 1.5.0.*) -- worked OK in 1.5, disabled in 2a1 & 3a1
  edited install.rdf to 3.0.* -- wouldn't work with 3, worked OK with 2
  edited install.rdf to 2.0.* -- disabled in 3, worked OK with 2
  restarted program: stopped working in 2
Then, when I just tweaked it again today to re-order the two RDF:Description tags, it started working again  in 2.  I don't recall moving them "out of 
order" when I originally tweaked, and can't think of a reason why I would 
have, but obviously that is very likely what happened, whether accidentally or as an experiment.

My query to you was strictly on the issue over whether order matters; compare 
to mimeTypes.rdf where (as far as I can tell) the various fields can appear in any order.

> Also, with a maxVersion of 2.0.* it will never work with 3.0a1.

The current version of DOMi wouldn't work for me on the trunk for TB even when 
I set the maxVersion number to 3.0.* -- I think it actually *is* incompatible, altho I haven't tried it lately.

Comment 46

[Robert Strong (they/them - no direct email)]

Since we only read one arc and there should only be one arc (e.g. entry) per targetApplication order doesn't matter. If we supported multiple arcs then it would read them all. So, if you have more than one arc for a single targetApplication order *might* matter but you shouldn't have more than one anyways.

btw: I usually just take the one from a corresponding Firefox build and it works for me or I build it myself.

Comment 47

[Mike Cowperthwaite]

The DOMi extension for TB got updated a while ago so that it started to load for 2.0b builds on its own.  For some reason, the min/max in the new extension are
  2.0b1
  2.0b2
and the extension stopped loading with nightlies in the past week or so -- I think because TB's UAstring now specifies
  2.0pre

This, incidentally, is the same basic problem I was running into at comment 43: 
I had set the maxversion to 2.0.* but it wouldn't match 2.0a1.  I eventually fixed that by tweaking the maxversion to 2.1, which I've done again now as a workaround.

Comment 48

[Magnus Melin [:mkmelin] (away until Aug 10)]

Firefox doesn't ship domi anymore either since bug bug 339229, but offer it through addons.mozilla.org (bug 271812). 

I guess the goal would be for the inspector to work on both product it doesn't according to comments in bug 271812. 

Tweaking summary as shipping it included is clearly wontfix at this point.

Comment 49

[Mark Banner (:standard8)]

Attachment: [checked in] Add inspector.xpt to TB's packages-static

inspector.xpt is generated as part of the core layout inspector code - therefore, we need to ship it as part of Thunderbird just like Firefox is now correcting in bug 420047.

Not sure if this is everything we need (still building), but it should be a good start.

Comment 50

[Mark Banner (:standard8)]

Comment on attachment 306336 [details] [diff] [review]
[checked in] Add inspector.xpt to TB's packages-static

Apparently Dan hasn't got review privs to /mail,  can you look at this please Magnus?

btw, based on my Linux build I think this will fix the problems people are seeing.

Comment 51

[Magnus Melin [:mkmelin] (away until Aug 10)]

Comment on attachment 306336 [details] [diff] [review]
[checked in] Add inspector.xpt to TB's packages-static

Sure, looks reasonable.

Comment 52

[Mark Banner (:standard8)]

Comment on attachment 306336 [details] [diff] [review]
[checked in] Add inspector.xpt to TB's packages-static

I've checked this in, could - once DOMI is available on amo, then please check a latest nightly (i.e. tomorrow's or afterwards) and see if it works.

Comment 53

[Joe Sabash [:JoeS1]]

Tested with hourly Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022814 Thunderbird/3.0a1pre ID:2008022814
Everthing seems fine. No errors in console.
Thanks much Mark.

Comment 54

[Phil Ringnalda (:philor)]

So, since the change to building inspector.xpt in layout landed on the 1.8 branch, does that mean that https://addons.mozilla.org/en-US/thunderbird/addon/1806 doesn't actually work in Tb 2 (other than on Mac, go go gadget no packaging), and we need this there as well?

Comment 55

[Phil Ringnalda (:philor)]

And for some odd reason, the answer is "no, we don't."

Comment 56

[Mark Banner (:standard8)]

(In reply to comment #53)
> Tested with hourly Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre)
> Gecko/2008022814 Thunderbird/3.0a1pre ID:2008022814
> Everthing seems fine. No errors in console.
> Thanks much Mark.

Marking as fixed. DOMI for trunk is (or will be) available here: 
https://addons.mozilla.org/en-US/thunderbird/addon/6622

Any specific/other problems with DOMI should be filed as separate bugs.

Note: per comment 48 shipping with DOMI is a wontfix.

Comment 57

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

Amazing! DOMi works great. Verified with version 3.0a1pre (2008030303).

Comment 59

[Joe]

What is the current status of this tool or any like it?

http://kb.mozillazine.org/DOM_Inspector points to this bug for an official tool but Scott MacGregor's extension is no longer.
MDN docs tutorial for basically "hello world" extension (https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Thunderbird_extensions/Building_a_Thunderbird_extension_5:_XUL) points to Scott extension too.

Searching AMO for "dom" reveals:
https://addons.mozilla.org/en-US/thunderbird/addon/dom-inspector-6622/?src=search (supported through TB 42)
https://addons.mozilla.org/en-US/thunderbird/addon/dom-inspector-dm/?src=search (experimental and only supported through TB 57)

I think that's it.


So what's the current tool or method to use?

Comment 60

[Joe]

Sorry, my error.  Bleary-eyed already forgot that TB is currently at 52.  I guess the experimental tool is only game in town then.
Should I update the MDN docs to point to that?  Is it acceptable to point to an experimental add-on?   
I'm a little leery of installing an add-on marked experimental myself as my TB is daily use.

Comment 61

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

Nowadays the `Tools | Developer Tools | Developer Toolbox` can be used to inspect elements.