Last Comment Bug 271812 - DOM Inspector not published to addons.mozilla.org
: DOM Inspector not published to addons.mozilla.org
Status: VERIFIED FIXED
:
Product: Release Engineering
Classification: Other
Component: Other (show other bugs)
: other
: All All
P1 major (vote)
: ---
Assigned To: Shawn Wilsher :sdwilsh
: build
:
Mentors:
https://addons.mozilla.org/en-US/fire...
: 339174 367621 399617 (view as bug list)
Depends on: toolkit@mozilla.org 333172 379109 388252 417697 419680 420767 421006 471481
Blocks: 339229 356916
  Show dependency treegraph
 
Reported: 2004-11-25 20:48 PST by David Adam
Modified: 2013-08-12 21:54 PDT (History)
46 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
v1.0 (3.98 KB, patch)
2008-02-26 12:11 PST, Shawn Wilsher :sdwilsh
no flags Details | Diff | Splinter Review
v1.0 (3.98 KB, patch)
2008-02-26 12:11 PST, Shawn Wilsher :sdwilsh
no flags Details | Diff | Splinter Review
generated xpi v1.0 (117.75 KB, application/x-xpinstall)
2008-02-26 12:20 PST, Shawn Wilsher :sdwilsh
no flags Details
v1.1 (3.93 KB, patch)
2008-02-26 12:39 PST, Shawn Wilsher :sdwilsh
mconnor: review+
Details | Diff | Splinter Review
generated xpi v1.1 (117.75 KB, application/x-xpinstall)
2008-02-26 12:40 PST, Shawn Wilsher :sdwilsh
no flags Details

Description User image David Adam 2004-11-25 20:48:49 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0

While we can install it through the installation process, there is no way to
install the DOM Inspector post-installation through u.m.o - is there still an
.xpi for the DOM Inspector that is compatible with Fx 1.0?

If so, can it be listed?

Reproducible: Always
Steps to Reproduce:
Comment 1 User image Wolf [:wolf] 2004-11-25 23:16:54 PST
If there is, is hasn't been submitted and I haven't seen a maintained XPI
available for it. It's probably located in the Windows-XPI or Linux-XPI
directories on the FTP under releases for Firefox 1.0 en-US.
Comment 2 User image alanjstr 2004-11-25 23:53:56 PST
I do not see a separate download for the DOMI XPI.  Even if it did exist, we'd
have to make sure we got the right localization, which UMO cannot currently
handle.  
Comment 3 User image Wolf [:wolf] 2004-11-26 00:24:34 PST
Clearing the target milestone since it's invalid and makes no sense for the
product at all.
Comment 4 User image Alex Vincent [:WeirdAl] 2004-11-28 20:25:43 PST
It might be nice to ask us DOM Inspector enthusiasts...
Comment 5 User image Alex Vincent [:WeirdAl] 2004-11-28 20:41:46 PST
Don't know where this one comes from:
ftp://ftp.mozilla.org/pub/mozilla.org/extensions/inspectorwidget/inspectorwidget-1.2-fx.xpi

Comment 6 User image alanjstr 2004-12-01 17:26:29 PST
Please see https://update.mozilla.org/extensions/moreinfo.php?id=63 for more
info.  I'd probably mark this as a duplicate of whatever put that one in. 
Although I'd like to see an official one from mozilla.org.  Like maybe one from
the official 1.0 release (hint hint)
Comment 7 User image alanjstr 2005-02-17 20:14:16 PST
I don't see an XPI in
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0/win32/xpi/
Comment 8 User image alanjstr 2005-02-28 18:15:53 PST
Here's the one for 1.0.1.  I guess adt stands for Advanced Developer Tools
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0.1/win32/xpi/adt.xpi
Comment 9 User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-04-30 22:23:10 PDT
It's listed now!
Comment 10 User image Cameron 2006-04-30 22:31:47 PDT
(In reply to comment #9)
> It's listed now!
> 
Where?
Comment 11 User image Nickolay_Ponomarev 2006-05-01 01:13:14 PDT
All I could find on AMO were these entries:
* https://addons.mozilla.org/firefox/2334/ "DOM Inspector Linux" (nicely not downloadable from a windows machine)
* https://addons.mozilla.org/firefox/1806/ "DOM Inspector" (saying it's compatible with Thunderbird 1.5 - 1.5.0.* Windows)
* https://addons.mozilla.org/firefox/1837/ "DOM Inspector - Mac OS X" (this one claiming compatibility with Thunderbird 1.5 - 1.5.0.* on all OS).

So while it's now true that DOMi is listed as an extension, I think that reporter expected the outcome of this bug to be a _single_ item listed on AMO, compatible with all apps (at least Fx+TB) on all major OS.
Comment 12 User image Cameron 2006-05-01 01:15:23 PDT
That confirms it's just not me being stupid then :)
Comment 13 User image Michael Morgan [:morgamic] 2006-06-22 13:38:50 PDT
AMO BUGSPAM FOR COMPONENT MOVE AND DELETE (FILTER ME)
Comment 14 User image Cameron 2006-06-24 12:13:20 PDT
AMO bugspam. Correcting QA contacts on OLD bugs (mozilla.update@update.bugs)

-> Correct QA contact (web-ui@add-ons.bugs)

Filtermeplzkthx
Comment 15 User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-11-01 07:58:16 PST
This isn't something we can really fix on the AMO side.  I think it's a build RFE to package and push DOMI packages as part of releases, excited as I'm sure they are to see this land in their laps.
Comment 16 User image :Gavin Sharp [email: gavin@gavinsharp.com] 2007-01-20 20:35:18 PST
*** Bug 367621 has been marked as a duplicate of this bug. ***
Comment 17 User image Shawn Wilsher :sdwilsh 2007-01-21 14:03:14 PST
Realistically, if we get Bug 333172 fixed, I should just be able to copy the xpi we have with our installers, and it should just "work" once we remove http://lxr.mozilla.org/seamonkey/source/extensions/inspector/install.rdf#53 from install.rdf (the comments would go too).

The question is do we want to have a build script to do this, or will I be doing it by hand?
Comment 18 User image Shawn Wilsher :sdwilsh 2007-05-02 06:10:20 PDT
Just updating.  A month or two ago I built a version out of the firefox 1.8 branch and mrbkap (I think) was using it at IBM.  Said it worked like a charm.  I still need to test and see if it will then work in Thunderbird as well, and if not, we need to build the inspector components in it as well.
Comment 19 User image Benjamin Smedberg [:bsmedberg] 2007-05-02 07:09:30 PDT
There aren't any binaries in DOMI from the 1.8.1 branch forward.
Comment 20 User image Shawn Wilsher :sdwilsh 2007-05-02 09:00:58 PDT
(In reply to comment #19)
> There aren't any binaries in DOMI from the 1.8.1 branch forward.
> 

Yeah, but what I haven't investigated is if other applications build the binary components that inspector uses or not.  Specifically, I'm looking at these:
http://mxr.mozilla.org/seamonkey/source/layout/inspector/
Comment 21 User image Shawn Wilsher :sdwilsh 2007-05-05 07:01:02 PDT
Ok, so I just installed a compiled version of the DOMi from the 1.8 branch into tbird 2, and I get too errors in the error console:
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"/>----^

I'll look into those and file bug(s) accordingly.
Comment 22 User image Shawn Wilsher :sdwilsh 2007-05-17 19:50:11 PDT
I had a nice lengthy comment, but Minefield crashed :(
So, to summarize, we have a few issues that are coming up.
1) We cannot use trunks version of DOMi on the branch because of interface changes.
2) branch is overlaying things it shouldn't be for thunderbird, so it doesn't work there.
3) AMO doesn't even allow for different versions of an extension to target different versions of an application.  See Bug 363050

In other words, two if fixable, but because of 1 and 3 we cannot have DOMi available to everyone easily.

There's also the issue of some extension on AMO already using the same id as ours, but I imagine that could be fixed.
Comment 23 User image timeless 2007-05-18 01:32:42 PDT
it's theoretically possible to take branch interfaces, rename them, commit them as privates in domi and write code in domi that qis to both interface names.

a renamed interface would be something like nsIFoo_MOZILLA_1_8_BRANCH

that's of course harder if you need to deal w/ linking or string issues, but I think that domi should probably be using glue for strings, and not linking against things in gecko, so it should be sufficient (minus some minor code bloat).

It should also be possible to have two .dlls generated instead of one and have one fail to register when it can't lookup the interface it needs or something.
Comment 24 User image Shawn Wilsher :sdwilsh 2007-05-18 08:19:16 PDT
that sounds hard :)

I think I could also reimplement the interface that has changed in JavaScript, and we could just remove the C++ code on trunk.  When we register, it will get the one in the extension.  I'll see if I can look into that today.
Comment 25 User image Shawn Wilsher :sdwilsh 2007-10-12 13:55:38 PDT
*** Bug 399617 has been marked as a duplicate of this bug. ***
Comment 26 User image John O'Duinn [:joduinn] (please use "needinfo?" flag) 2007-10-31 12:22:07 PDT
*** Bug 339174 has been marked as a duplicate of this bug. ***
Comment 27 User image John O'Duinn [:joduinn] (please use "needinfo?" flag) 2007-11-04 23:50:01 PST
Found during Build&Release triage. Not sure what is for Build team. Seems like this should be reassigned to addons.mozilla.org? 
Comment 28 User image Shawn Wilsher :sdwilsh 2007-11-05 05:07:40 PST
It's not clear where this bug should live, but I'm certainly the owner of it :/
Comment 29 User image Benjamin Smedberg [:bsmedberg] 2007-11-05 06:17:25 PST
John, this is definitely something that build&release will need to do, because it requires building DOMI and signing the .xpi... how we get it to addons at that point is mostly immaterial
Comment 30 User image Shawn Wilsher :sdwilsh 2007-11-05 06:24:27 PST
Does it really need to be signed?  Do we sign any other mozilla.org addons like Chatzilla?
Comment 31 User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2007-11-05 09:50:57 PST
It should be signed, just as it's signed when shipped as part of the dominant installation mechanism for Fx2.  Let's not regress here.
Comment 32 User image John O'Duinn [:joduinn] (please use "needinfo?" flag) 2007-11-05 10:21:54 PST
How do we currently sign addons? Its not part of any manual build&release instructions that I know of, and is definitely not part of any automation so far. Any pointers would be great! 

As an aside, we installed renewed keys on build machines last week. One of those keys was a mystery key, which eventually turned out to be a key for signing addons/extensions that had been expired since june2007, and as far as we can tell, has never ever used since it was first created, or since it expired. For details, see bug#401284

  
Comment 33 User image Benjamin Smedberg [:bsmedberg] 2007-11-05 10:34:55 PST
As noted on IRC a while back, http://developer.mozilla.org/en/docs/Code_snippets:Signing_a_XPI
 
We have to figure out a good way to build the DOMI .xpi before we go about signing it, of course... on trunk it should be really easy to make a standalone DOMI configure/build process (--enable-application=extensions/inspector)... on branches we'd have to use a bit more hackery... who owns DOMI and can decide what versions we want to publish on AMO?
Comment 34 User image Shawn Wilsher :sdwilsh 2007-11-05 11:42:15 PST
(In reply to comment #33)
> As noted on IRC a while back,
> http://developer.mozilla.org/en/docs/Code_snippets:Signing_a_XPI
For what it's worth, I couldn't get those instructions to work when I tried them ~a year ago, but things may have changed/gotten easier.

> We have to figure out a good way to build the DOMI .xpi before we go about
> signing it, of course... on trunk it should be really easy to make a standalone
> DOMI configure/build process (--enable-application=extensions/inspector)... on
> branches we'd have to use a bit more hackery... who owns DOMI and can decide
> what versions we want to publish on AMO?
When I want a standalone xpi of the DOMi, I just |make -C extensions/inspector| in my object directory, and there's a nice xpi sitting in dist/xpi-stage/

Our branch situation isn't pretty, and I know for a fact that the branch doesn't work in Thunderbird due to some missing entities.  That would have to be resolved first.  Also, we can only have one version up on amo - we cannot offer a version for 1.8.1 and one for 1.9.  The trunk version of DOMi depends on binary changes, so that xpi won't work on 1.8.1, and the xpi generated from 1.8.1 essentially sucks compared to what's in 1.9.

As for who owns DOMi - there's no official owner.  timeless was the one doing reviews for the most part, then I started to take over for that.
Comment 35 User image benc 2008-02-18 12:42:29 PST
Shawn:

When I search the a.m.o site for DOM inspector, I do see a version that mscott posted that is supposed to work with Thunderbird.

Are you saying that this Thunderbird-specific version is not working as well?

Also, now that mscott is leaving mozilla.org, do we know if he intends to maintain that as a contributor?
Comment 36 User image Shawn Wilsher :sdwilsh 2008-02-18 14:08:03 PST
Note, this bug is not yet resolved, as in I haven't yet put it on amo.  It's on the todo list (hopefully next week actually).

I don't ever recall implying it wasn't working for thunderbird.  I also was unaware of mscott leaving mozilla.org (he did leave the Mozilla corporation, which is a separate entity).

The version I'll be posting to amo should be compatible with thunderbird 3.0 (anything built off of gecko 1.9).
Comment 37 User image benc 2008-02-19 00:47:25 PST
(good point about mscott. When I worked for/on mozilla, there was no mozilla.com... what I meant was, I as someone that reads a bit of news, it wasn't clear to me if he was going to keep fixing it, whatever capacities he retains in any mozilla organizations...)
Comment 38 User image Reed Loden [:reed] (use needinfo?) 2008-02-25 23:33:47 PST
Now that bug 339229 has been "fixed", this should be a top priority, imho, considering DOMi isn't being shipped anymore.
Comment 39 User image Shawn Wilsher :sdwilsh 2008-02-26 06:27:56 PST
It doesn't really matter if it's blocking or not...I'm fixing it this week regardless...
Comment 40 User image Shawn Wilsher :sdwilsh 2008-02-26 12:11:24 PST
Created attachment 305819 [details] [diff] [review]
v1.0

This has the necessary changes to get DOMi working as a standalone add-on.  Looking for r and sr, even though I can't request both.
Comment 41 User image Shawn Wilsher :sdwilsh 2008-02-26 12:11:59 PST
Created attachment 305820 [details] [diff] [review]
v1.0

This has the necessary changes to get DOMi working as a standalone add-on.  Looking for r and sr, even though I can't request both.
Comment 42 User image Shawn Wilsher :sdwilsh 2008-02-26 12:12:49 PST
Comment on attachment 305819 [details] [diff] [review]
v1.0

hey - I only clicked submit once :(
Comment 43 User image Shawn Wilsher :sdwilsh 2008-02-26 12:20:26 PST
Created attachment 305821 [details]
generated xpi v1.0

the associated xpi
Comment 44 User image Robert Kaiser 2008-02-26 12:26:03 PST
Comment on attachment 305820 [details] [diff] [review]
v1.0

>diff --git a/extensions/inspector/install.rdf b/extensions/inspector/install.rdf
>--- a/extensions/inspector/install.rdf
>+++ b/extensions/inspector/install.rdf
>@@ -1,19 +1,17 @@
> <?xml version="1.0"?>
>-
>-#filter substitution
> 
> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>      xmlns:em="http://www.mozilla.org/2004/em-rdf#">
>   <Description about="urn:mozilla:install-manifest">
>     <em:id>inspector@mozilla.org</em:id>
>-    <em:version>@EXTENSION_VERSION@</em:version>
>+    <em:version>2.0.0</em:version>

Why not leave the filter and use DOMi_VERSION here?
Comment 45 User image Shawn Wilsher :sdwilsh 2008-02-26 12:39:53 PST
Created attachment 305825 [details] [diff] [review]
v1.1

that's a fair point
Comment 46 User image Shawn Wilsher :sdwilsh 2008-02-26 12:40:34 PST
Created attachment 305826 [details]
generated xpi v1.1
Comment 47 User image Shawn Wilsher :sdwilsh 2008-02-27 18:22:39 PST
Checking in extensions/inspector/Makefile.in;
new revision: 1.24; previous revision: 1.23
Checking in extensions/inspector/install.rdf;
new revision: 1.17; previous revision: 1.16

Posted to AMO
https://addons.mozilla.org/en-US/firefox/addon/6622
Comment 48 User image Joe Sabash [:JoeS1] 2008-02-27 20:40:05 PST
(In reply to comment #36)
> Note, this bug is not yet resolved, as in I haven't yet put it on amo.  It's on
> the todo list (hopefully next week actually).
> 
> I don't ever recall implying it wasn't working for thunderbird.  I also was
> unaware of mscott leaving mozilla.org (he did leave the Mozilla corporation,
> which is a separate entity).
> 
> The version I'll be posting to amo should be compatible with thunderbird 3.0
> (anything built off of gecko 1.9).
> 

I'm afraid not.
Still does not work for Tbird trunk.
Well, it does partially work, but no info if the Dom nodes pane, other panes seem OK
Error console:
Error: XPCU is not defined
Source File: chrome://inspector/content/viewers/accessibleEvents/accessibleEvents.js
Line: 180
As well as others errors, that I can't reproduce at the moment.
Comment 49 User image Joe Sabash [:JoeS1] 2008-02-27 20:57:37 PST
Hmmm..
That error above seems to stick,(keeps re occuring when cleared) even if Domi is closed.
This persisted until I restarted TB trunk.
Here is the other error:
Error: viewer is undefined
Source File: chrome://inspector/content/viewers/dom/dom.js
Line: 71
Comment 50 User image Darren VanBuren 2008-02-27 21:05:54 PST
this is so freaking we todd ed! We can't keep the DOM Inspector seperate from the main browser. I'm downgrading to 2 and never moving up. Possibly even never using Firefox again.
Comment 51 User image Shawn Wilsher :sdwilsh 2008-02-27 21:10:24 PST
Please file any follow-up issues as new bugs.  I didn't change any code in the DOM inspector by doing this, so these issues existed before the changes in this bug.
Comment 52 User image Joe Sabash [:JoeS1] 2008-02-27 21:13:23 PST
Sorry for the spam, but this is holding at least 2 Tbird extension writers up that I know of.
Error: null has no properties
Source File: chrome://inspector/content/viewers/dom/dom.js
Line: 87
That's with the first invocation of Domi
Comment 53 User image Philip Chee 2008-02-28 00:23:54 PST
> Sorry for the spam, but this is holding at least 2 Tbird extension writers up
> that I know of.

If you use the SeaMonkey version of the trunk DOM Inspector using the procedure detailed in <http://forums.mozillazine.org/viewforum.php?f=19> (Getting a working DOM Inspector in Thunderbird 3.0a trunk) Do you still get these errors?
Comment 54 User image Magnus Melin 2008-02-28 09:16:28 PST
For thunderbird -> bug 254031.
Comment 55 User image Henrik Skupin (:whimboo) [away 02/18 - 02/27] 2008-03-02 23:55:38 PST
Great to see that DOMi is now official available on AMO.

Verified.
Comment 56 User image Henrik Skupin (:whimboo) [away 02/18 - 02/27] 2008-03-03 02:10:06 PST
Shawn, when I install DOMi the installation panel states an unknown author for that extension. Could you please solve this issue? Shall I file a new bug therefor?
Comment 57 User image Philip Chee 2008-03-03 02:17:44 PST
For the author to show up, the extension has to be signed.
Comment 58 User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-03-03 11:44:18 PST
Yes, file a separate bug for signing it, and discuss it there.

Note You need to log in before you can comment on or make changes to this bug.