193486 - Make Inspector work on Mozilla Firebird

Status: VERIFIED FIXED

(Other Applications :: DOM Inspector, defect)

Description

[Chris Cook]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030207 Phoenix/0.5

I would like to port the DOM inspector to work on Phoenix (as an extension even)
and I know I am not the only one working on this or wishing it to be done.
Assuming that it can be made to work without much difficulty, I believe it would
be desirable to patch the trunk version with patches required by Phoenix rather
than creating a fork. I will add some patches when I can make them although I've
only dealth with interface overlay issues so far.  I believe there may be
underlying changes required but haven't determined that yet.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

Thanks for doing this!

Comment 2

[Asa Dotzler [:asa]]

This shouldn't be terribly difficult. Hewitt has provided the XPI frontend and
palette button as part of his mozEngineer extension at
http://joehewitt.com/mozilla/mozengineer/  I suppose that what needs to happen
(just a guess) is that the backend, that code which gets build when you
--enable-extension=inspector (or whatever the flag is) needs to be built and
combined with the mozEngineer XPI to provide a complete DOM Inspector extension. 

Comment 3

[Chris Neale]

DOM Inspector (built in, by cvs route) is better IM<HO than MozEngineer,

although one problem to be overcome is the menus of DOM Inspector,
which appear (I haven't checked yet) to come via navigatorOverlay.xul, which is
included in navigator.xul, whereas  TBFKAphoenix has its menus defined in
browser.xul, not a separate overlay

Comment 4

[Chris Neale]

correction: DOM Inspector gets it's menus from 

<?xul-overlay href="chrome://communicator/content/utilityOverlay.xul"?>

and further overlays to that I presume

Comment 5

[Chris Cook]

Attachment: /content/inspector/contents.rdf with overlay changes for Phoenix

Added the overlays for menu changes to make inspector available in the "Tools"
menu in Phoenix. Assumed that the "Web Development" submenu would not exist so
placed in the main menu under the "Javascript Console" menu item. Original file
came from the inspector distributed with Mozilla 1.3b release. I don't
currently have the facility to make patches so uploading this in the meantime.

Comment 6

[Chris Cook]

Attachment: /content/inspector/tasksOverlay.xul with changes for Phoenix

Added a menu item for Phoenix to make it appear in the "Tools" menu under the
"Javascript Console" menu item.

Comment 7

[Chris Cook]

Comment on attachment 116043 [details]
/content/inspector/contents.rdf with overlay changes for Phoenix

Oops. I lied. This is from an older version.

Comment 8

[Chris Cook]

Attachment: /content/inspector/contents.rdf with overlay changes for Phoenix

This is updated from the 1.3b version.

Comment 9

[Chris Neale]

Attachment: amended changes to tasksOverlay.xul

added the shortcut Ctrl-Shift-i

Comment 10

[Chris Cook]

Comment on attachment 116045 [details]
/content/inspector/tasksOverlay.xul with changes for Phoenix

cdn's amendment looks good.

Comment 11

[Chris Cook]

So far I have been unable to make inspector work with the standard Phoenix
build. It loads up just fine but "inspecting" anything is impossible. I receive
an exception with the following:

Error: uncaught exception: [Exception... "Invalid ClassID or ContractID" 
nsresult: "0x80570017 (NS_ERROR_XPC_BAD_CID)"  location: "JS frame ::
chrome://inspector/content/jsutil/system/file.js :: <TOP_LEVEL> :: line 121" 
data: no]

However, a Phoenix build that has been built with inspector included also has
this same exception so I am unsure if it is relevent.

Can anyone confirm if inspector requires some xpcom or else to be compiled in to
work? If this is the case then using inspector with the standard Phoenix build
is a no go and I'm wasting my time.

Also, in the absence of further errors in JS console (other than the one
mentioned above), I am at a loss as to where to look to determine why inspector
doesn't work.

Suggestions would be greatly appreciated.

Comment 12

[Chris Cook]

Attachment: Screenshot of broken inspector

Here is a screenshot of what I have so far. Inspector launches from Phoenix
(nightly 03/20) and by typing in a URL and clicking the inspect button it
browses a webpage (or chrome equally well). As you can see the top half of
inspector is disabled and functionless. Additionally, the "inspect a window"
action displays all active windows (including Phoenix) but is broken and does
not even generate an exception in the js console.

Comment 13

[Chris Neale]

.mozconfig used to build on Linux

export MOZ_PHOENIX=1
mk_add_options MOZ_PHOENIX=1
ac_add_options --enable-crypto
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-mailnews
ac_add_options --disable-composer
ac_add_options --enable-optimize=-O2
ac_add_options --disable-ldap
ac_add_options --enable-plaintext-editor-only
ac_add_options --without-system-nspr

this doesn't explicitly include inspector, although it is built, gives the JS
error and works to an extent

Comment 14

[Alex Vincent [:WeirdAl]]

Per the new roadmap this is no longer an enhancement bug.  Maybe I'm
overreacting by making it major, but it's at least normal.  Mr. Cook, could you
please review the roadmap and respond accordingly?

(I dislike surprises, which is why I'm probably overreacting.)

Comment 15

[Alex Vincent [:WeirdAl]]

Re comment 11:
http://lxr.mozilla.org/seamonkey/source/extensions/inspector/resources/content/jsutil/system/file.js

Yes, there is some XPCOM/XPConnect involved in Inspector.  For instance,
nsIFlasher is an interface I discovered Inspector using when I went hacking
around in its source.

That particular error is known, but it does not interfere with DOM Inspector's
loading a document.  So something else is going on.

No, I don't know how to hack XPCOM/XPConnect.

Comment 16

[Alex Vincent [:WeirdAl]]

bug 189950 for the error in comment 11.  I'll probably fix it in the next 48 hours.

Comment 17

[Chris Cook]

Re comment 14:
I've reviewed the roadmap but I am not certain what kind of response you're
looking for. It would seem that under the new plan, whatever is necessary to
make inspector work is what will be done. It is unclear to me for now what build
changes will take place (with the removal of the MOZ_PHOENIX #ifdefs and etc.)
but assuming that future Phoenix builds will include all necesary XPCOM, then
inspector should work with only the overlay changes I've submitted so far.

Comment 18

[alanjstr]

DOM Inspector has been successfully built in on Linux and Win32 (builds have
been posted on MozillaZine) with the need to also install mozEngineer as
mentioned.  Is there anything preventing this being an extension, like currently
being too closely tied into the core code?  

My understanding of the roadmap is that DOM Inspector and Venkman will become
extensions.  Could DOM Inspector extension be combined with mozEngineer?

Comment 19

[TychoQuad]

I say this be made into an extension. Many people use it, but many, many more
would rather it not be there. (many people also don't want the javascript
debugger there:P)

Comment 20

[Chris Cook]

RE: #18
Inspector relies on a fair amount of XPCOM/XPConnect code to be compiled into
the gecko core at the moment in order to work. This extra code is not currently
compiled into the firebird builds so, yes, there is something preventing
inspector from being a simple extension. Additionally, MozEngineer is only a
hack that adds an interface to access inspector (if it is already installed) and
nothing more.

The question is not whether inspector would be a good extension or should be
built into the app by default. It is simply a matter of time to reorganize the
projects per the new roadmap.

Comment 21

[alanjstr]

Perhaps you haven't seen the thread on MozillaZine.

http://www.mozillazine.org/talkback.html?article=3216

Comment 22

[alanjstr]

Though that is available only as an XPI for Win32.  But it should show that DOMI
can be seperated.

Comment 23

[Boris Zbarsky [:bzbarsky]]

Chris, the only parts of inspector that have to be built into the "gecko core"
are the nsIInspectorCSSUtils/nsInspectorCSSUtils files in
content/html/style/src/.  I rather doubt that firebird compiles those out....

Now parts of Inspector _are_ written in C++.  So creating a cross-platform
inspector XPI would mean that those parts would need to be compiled into the
base browser install.  But if we just want to be able to have Inspector as an
add-on and don't mind separate XPIs per platform, there is nothing preventing
that, as far as I can tell.

Comment 24

[Chris Cook]

I haven't had time to look at this for a while and won't in the foreseeable future.

-> Owner

Comment 25

[Christopher Aillon (sabbatical, not receiving bugmail)]

Actually, wow, what timing.  I started looking at firebird last night and was
considering doing some work here.

Comment 26

[Mickey Stein]

I'd been applying the patches above in my linux builds and having no problems
with DOM in firebird until today. Today, a couple of minor changes were made to
the source so a straight-ahead patch can't locate correctly. They're locale /
skin changes from V1.5a to 1.5b as follows in the 'contents.rdf' patch:

+++ extensions/inspector/resources/content/contents.rdf 3 Aug 2003 16:41:09 -000
0
@@ -12,6 +12,9 @@
         chrome:displayName="Document Inspector"
         chrome:author="Joe Hewitt"
         chrome:name="inspector"
+        chrome:extension="true"
+        chrome:settingsURL="chrome://inspector/content/prefs/pref-inspector-dlg
.xul"
+        chrome:description="Allows viewing and modifying the object model of a
web page."
         chrome:localeVersion="1.5b"
         chrome:skinVersion="1.5">

After the last two lines are changed as shown above, the patches work fine again. 

Comment 27

[Christopher Aillon (sabbatical, not receiving bugmail)]

Mass re-assigning bugs to [e-mail]

Comment 28

[scragz]

Attachment: Patch to titledSplitter.xml for bindings to widgets change

This and the patch to treeEditable.diff will get the inspector working in
recent FB nightlies. Doesn't help the main problem of having it have to be
compiled in, but at least it's usablewith this.

Comment 29

[scragz]

Attachment: Patch to treeEditable.xml for bindings to widgets change

Comment 30

[Christopher Aillon (sabbatical, not receiving bugmail)]

Do these changes break inspector for seamonkey?  If not I'm cool with the
change, but please find someone who knows this stuff to do the review...

Comment 31

[Chris Neale]

I expect that the xul overlay patches won't break seamonkey,
but the bindings -> widgets patches for the xbl probably will, given that
without the [b->w] patches Firebird DOM Inpector uses bindings references that
are no longer built

Comment 32

[alanjstr]

That contents.rdf overlay is old.  Is it completely obsolete, or should a patch
still be made for contents.rdf?  

Comment 33

[alanjstr]

Also, should treeEditable.xml have a change for <binding id="treecellEditable"
extends="chrome://global/content/bindings/tree.xml#treecell"> ?

Comment 34

[Robert Kaiser]

I'd badly need inspector for theme development in FB but can't risk breaking
Seamonkey as it's my main browser and both are built from one source tree
here... Is inspector able to work in FB currently?

Comment 35

[alanjstr]

I have been able to build Firebird 0.7 for Win32 with the above changes and a
few tweaks.  Once I get one more menu item I'll work on creating patches for
contents.rdf and tasksOverlay.xul

Comment 36

[alanjstr]

Attachment: Patch to contents.rdf to add Firebird overlays

Comment 37

[alanjstr]

Attachment: Patch to tasksOverlay.xul to add Firebird overlays

Comment 38

[alanjstr]

I seem to be missing "Inspect this page" when I build.  Can anyone spot what's
wrong?

Comment 39

[alanjstr]

Menubar changes can also be made via browser/base/content/browser-menubar.inc
http://shill.homeip.net/diffs/browser-menubar.diff

browser/base/content/browser-scripts.inc
http://shill.homeip.net/diffs/browser-scripts.diff

The obvservation was made that "Insert (via zip, winzip, whatever) this file
"./xpfe/global/resources/content/globalOverlay.xul" (from the source dir) into
toolkit.jar from the chrome directory. Why toolkit.jar? It doesn't really matter
because all of the ingredients of any .jar file wind up looking the same to the
browser once the engine is loaded. (i.e. chrome://global/... ) "

Comment 40

[Mickey Stein]

from #39:

"The obvservation was made that "Insert (via zip, winzip, whatever) this file
"./xpfe/global/resources/content/globalOverlay.xul" (from the source dir) into
toolkit.jar from the chrome directory. Why toolkit.jar? It doesn't really matter
because all of the ingredients of any .jar file wind up looking the same to the
browser once the engine is loaded. (i.e. chrome://global/... ) ""

I'm the culprit that came up with that nutty kludge to get past the
overlayGlobal.xul error when invoking either DOMi or Venkman, but I realize its
nothing but a (poor at best) workaround. I'm still trying to figure out when
this started occurring (just the missing overlay part) and so far, I've narrowed
it down to 4-Oct -> 7-Oct. I'm running a couple of builds, and as I compare the
one from 3-Oct to the later ones with the error, I realize that there *never*
was an instance of 'globalOverlay.xul' in any of the .jar files in chrome. 

The other thing is that I only put globalOverlay.xul in toolkit.jar because it
seemed more generic than putting it in some other .jar file that was only for
one thing when the problem appears to be more systemic and likely in the code. 

Still looking, as usual. 

Comment 41

[Steffen Wilberg]

Ben fixed this today:
http://bonsai.mozilla.org/cvsquery.cgi?date=explicit&mindate=11%2F12%2F2003+01%3A15&maxdate=11%2F12%2F2003+01%3A31

It will be included in all future zip builds and the installer.
If you use the installer, you can choose whether or not to install it
("developer tools").

Over to Ben...

Comment 42

[Steffen Wilberg]

...and marking fixed.

Please file separate bugs for issues with DOMi in Firebird.

Comment 43

[Bill Mason]

v