Closed Bug 193486 Opened 21 years ago Closed 21 years ago

Make Inspector work on Mozilla Firebird

Categories

(Other Applications :: DOM Inspector, defect)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: beerfan, Assigned: bugs)

References

Details

Attachments

(7 files, 2 obsolete files)

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:
Thanks for doing this!
Assignee: caillon → cd_cook
Status: UNCONFIRMED → NEW
Ever confirmed: true
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. 
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
correction: DOM Inspector gets it's menus from 

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

and further overlays to that I presume
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.
Added a menu item for Phoenix to make it appear in the "Tools" menu under the
"Javascript Console" menu item.
Comment on attachment 116043 [details]
/content/inspector/contents.rdf with overlay changes for Phoenix

Oops. I lied. This is from an older version.
Attachment #116043 - Attachment is obsolete: true
This is updated from the 1.3b version.
added the shortcut Ctrl-Shift-i
Comment on attachment 116045 [details]
/content/inspector/tasksOverlay.xul with changes for Phoenix

cdn's amendment looks good.
Attachment #116045 - Attachment is obsolete: true
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.
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.
.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
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.)
Severity: enhancement → major
Summary: RFE: Make Dom Inspector work on Phoenix → Make Inspector work on Phoenix
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.
bug 189950 for the error in comment 11.  I'll probably fix it in the next 48 hours.
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.
Summary: Make Inspector work on Phoenix → Make Inspector work on Mozilla Firebird
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?
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)
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.
Perhaps you haven't seen the thread on MozillaZine.

http://www.mozillazine.org/talkback.html?article=3216
Though that is available only as an XPI for Win32.  But it should show that DOMI
can be seperated.
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.
I haven't had time to look at this for a while and won't in the foreseeable future.

-> Owner
Assignee: tangent → caillon
Actually, wow, what timing.  I started looking at firebird last night and was
considering doing some work here.
Status: NEW → ASSIGNED
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. 
Mass re-assigning bugs to dom.inspector@extensions.bugs
Assignee: caillon → dom.inspector
Status: ASSIGNED → NEW
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.
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...
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
That contents.rdf overlay is old.  Is it completely obsolete, or should a patch
still be made for contents.rdf?  
Also, should treeEditable.xml have a change for <binding id="treecellEditable"
extends="chrome://global/content/bindings/tree.xml#treecell"> ?
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?
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
I seem to be missing "Inspect this page" when I build.  Can anyone spot what's
wrong?
Blocks: 214269
Depends on: 189950
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/... ) "
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. 
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...
Assignee: dom-inspector → bugs
...and marking fixed.

Please file separate bugs for issues with DOMi in Firebird.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
Product: Core → Other Applications
QA Contact: timeless → dom-inspector
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: