Closed
Bug 193486
Opened 21 years ago
Closed 21 years ago
Make Inspector work on Mozilla Firebird
Categories
(Other Applications :: DOM Inspector, defect)
Other Applications
DOM Inspector
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: beerfan, Assigned: bugs)
References
Details
Attachments
(7 files, 2 obsolete files)
2.67 KB,
text/plain
|
Details | |
1.45 KB,
text/plain
|
Details | |
65.36 KB,
image/jpeg
|
Details | |
981 bytes,
patch
|
Details | Diff | Splinter Review | |
1.44 KB,
patch
|
Details | Diff | Splinter Review | |
2.43 KB,
patch
|
Details | Diff | Splinter Review | |
1.51 KB,
patch
|
Details | Diff | Splinter Review |
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•21 years ago
|
||
Thanks for doing this!
Assignee: caillon → cd_cook
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
correction: DOM Inspector gets it's menus from <?xul-overlay href="chrome://communicator/content/utilityOverlay.xul"?> and further overlays to that I presume
Reporter | ||
Comment 5•21 years ago
|
||
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.
Reporter | ||
Comment 6•21 years ago
|
||
Added a menu item for Phoenix to make it appear in the "Tools" menu under the "Javascript Console" menu item.
Reporter | ||
Comment 7•21 years ago
|
||
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
Reporter | ||
Comment 8•21 years ago
|
||
This is updated from the 1.3b version.
Comment 9•21 years ago
|
||
added the shortcut Ctrl-Shift-i
Reporter | ||
Comment 10•21 years ago
|
||
Comment on attachment 116045 [details]
/content/inspector/tasksOverlay.xul with changes for Phoenix
cdn's amendment looks good.
Attachment #116045 -
Attachment is obsolete: true
Reporter | ||
Comment 11•21 years ago
|
||
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.
Reporter | ||
Comment 12•21 years ago
|
||
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•21 years ago
|
||
.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•21 years ago
|
||
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
Comment 15•21 years ago
|
||
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•21 years ago
|
||
bug 189950 for the error in comment 11. I'll probably fix it in the next 48 hours.
Reporter | ||
Comment 17•21 years ago
|
||
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.
Updated•21 years ago
|
Summary: Make Inspector work on Phoenix → Make Inspector work on Mozilla Firebird
Comment 18•21 years ago
|
||
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•21 years ago
|
||
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)
Reporter | ||
Comment 20•21 years ago
|
||
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•21 years ago
|
||
Perhaps you haven't seen the thread on MozillaZine. http://www.mozillazine.org/talkback.html?article=3216
Comment 22•21 years ago
|
||
Though that is available only as an XPI for Win32. But it should show that DOMI can be seperated.
Comment 23•21 years ago
|
||
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.
Reporter | ||
Comment 24•21 years ago
|
||
I haven't had time to look at this for a while and won't in the foreseeable future. -> Owner
Assignee: tangent → caillon
Comment 25•21 years ago
|
||
Actually, wow, what timing. I started looking at firebird last night and was considering doing some work here.
Status: NEW → ASSIGNED
Comment 26•21 years ago
|
||
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•21 years ago
|
||
Mass re-assigning bugs to dom.inspector@extensions.bugs
Assignee: caillon → dom.inspector
Status: ASSIGNED → NEW
Comment 28•21 years ago
|
||
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•21 years ago
|
||
Comment 30•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
That contents.rdf overlay is old. Is it completely obsolete, or should a patch still be made for contents.rdf?
Comment 33•21 years ago
|
||
Also, should treeEditable.xml have a change for <binding id="treecellEditable" extends="chrome://global/content/bindings/tree.xml#treecell"> ?
Comment 34•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
Comment 37•21 years ago
|
||
Comment 38•21 years ago
|
||
I seem to be missing "Inspect this page" when I build. Can anyone spot what's wrong?
Comment 39•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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
Comment 42•21 years ago
|
||
...and marking fixed. Please file separate bugs for issues with DOMi in Firebird.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Core → Other Applications
Updated•17 years ago
|
QA Contact: timeless → dom-inspector
You need to log in
before you can comment on or make changes to this bug.
Description
•