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

VERIFIED FIXED in Thunderbird 3

Status

defect
VERIFIED FIXED
15 years ago
11 months ago

People

(Reporter: whimboo, Assigned: standard8)

Tracking

Trunk
Thunderbird 3
Bug Flags:
blocking-aviary1.0PR -
blocking-aviary1.5 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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?
Asking for blocking aviary1.0PR?
Flags: blocking-aviary1.0PR?

Comment 2

15 years ago
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

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

Comment 4

15 years ago
available as an extension.  trying to keep tbird download small and simple.
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
(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.
(In reply to comment #4)
> available as an extension

No, it isn't

Comment 7

15 years ago
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

15 years ago
I thought it was part of the .ZIP for those that wanted it?
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...
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?
Flags: blocking-aviary1.1?
OS: Windows 2000 → All
Hardware: PC → All
I can't see why we'd hold up shipping Thunderbird for this. For Firefox, I could
see, since web developers might want it. 
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

14 years ago
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.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
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.
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?
Summary: DOM inspector extension not shipped with Thunderbird → DOM inspector extension not shipped for Thunderbird

Comment 16

14 years ago
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

14 years ago
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

14 years ago
(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 ?
(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.

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

14 years ago
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

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

Comment 23

14 years ago
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.
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

14 years ago
I want to vote on this too. It's very hard to develop extensions for thunderbird without it.
I also want to vote for adding the DOM inspector to Thunderbird, it is a very convenient for development

Comment 27

14 years ago
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.
(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.
(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.
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?
(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

14 years ago
(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

14 years ago
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

14 years ago
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.
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

13 years ago
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
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

13 years ago
Homepage has nothing to do with updates.
Any plans of making the DOM Inspector available for linux? 

Comment 41

13 years ago
the linux version is on addons. Maybe it's still in the review queue if it hasn't shown up yet. 
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.)
(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.
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.
(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.
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.
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.
QA Contact: general

Updated

11 years ago
Flags: blocking-thunderbird3?
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.
Assignee: mscott → nobody
Summary: DOM inspector extension not shipped for Thunderbird → DOM inspector from addons.mozilla.org needs to work on thunderbird
(Assignee)

Comment 49

11 years ago
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.
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Attachment #306336 - Flags: superreview?(dmose)
Attachment #306336 - Flags: review?(dmose)
(Assignee)

Comment 50

11 years ago
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.
Attachment #306336 - Flags: superreview?(dmose)
Attachment #306336 - Flags: review?(mkmelin+mozilla)
Attachment #306336 - Flags: review?(dmose)
Comment on attachment 306336 [details] [diff] [review]
[checked in] Add inspector.xpt to TB's packages-static

Sure, looks reasonable.
Attachment #306336 - Flags: review?(mkmelin+mozilla) → review+
(Assignee)

Comment 52

11 years ago
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.
Attachment #306336 - Attachment description: Add inspector.xpt to TB's packages-static → [checked in] Add inspector.xpt to TB's packages-static
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.
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?
And for some odd reason, the answer is "no, we don't."
(Assignee)

Comment 56

11 years ago
(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.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Flags: blocking-thunderbird3?
Resolution: --- → FIXED
Version: unspecified → Trunk
Amazing! DOMi works great. Verified with version 3.0a1pre (2008030303).
Status: RESOLVED → VERIFIED
Target Milestone: --- → Thunderbird 3
Duplicate of this bug: 356916

Comment 59

11 months ago
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

11 months ago
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.
Nowadays the `Tools | Developer Tools | Developer Toolbox` can be used to inspect elements.
You need to log in before you can comment on or make changes to this bug.