User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.9b4pre) Gecko/2008021302 Mnenhy/0.7.5.0 SeaMonkey/2.0a1pre XpcomViewer/0.9 Build Identifier: DOM Inspector can be installed in ChatZilla running on XULrunner, but there is no overlay support for it. ChatZilla doesn't have a "Tools" or "Tasks" menu. Maybe adding it to the Main Menu (same as Addons, JavaScript Console and Advanced Configuration) would be possible? I've tried two methods: 1. modifying the current DOMi 2.0 extension, I added: <em:targetApplication> <!-- Chatzilla standalone on XULrunner--> <Description> <em:id>{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}</em:id> <em:minVersion>0.9.7</em:minVersion> <em:maxVersion>0.9.*</em:maxVersion> </Description> </em:targetApplication> in install.rdf This installs DOMi, but there is no way to launch it. 2) Copying an installed DOMi from Firefox 3 RC1 into the ChatZilla folder (or the profile). This works too, but I can't find the way to launch both Chatzilla and DOMi. Reproducible: Always Steps to Reproduce: 1. 2. 3.

You can use the -inspector commandline option, I believe.

on irc, it was indicated that chatzilla would not open then

oh, that's pretty lame. What happens if you use both -chat and -inspector ?

(In reply to comment #3) > oh, that's pretty lame. What happens if you use both -chat and -inspector ? > That works! When I tried earlier, I omitted the "-chat" flag I used a shortcut from the desktop: "C:\Program Files\Chatzilla09821\xulrunner.exe" application.ini -inspector -chat -no-remote -p and that launched both ChatZilla and DOMi windows (DOMi being installed in this folder, for all ChatZilla profiles).

Mmhmm. Bug is still valid though. Could do with a ChatZilla overlay in DOMI. It's like one xul file and a line in chrome.manifest? Shawn?

yeah, that's about all it'd take

Hello, I know it's lame, but could this bug be fixed? Support for Chatzilla/XULRunner by DOMi would be really nice! Thanks

Since this file did not exist in the tree beforehand, hg diff doesn't produce anything for it. Devmo is unhelpful, because it only lists ways to handle this for CVS, not Mercurial.

hg add should work just fine. In cvs you could not do this unless you had commit access.

Comment on attachment 380739 [details] chatzilla-specific overlay If you could please, get a patch up that has this file |hg add|ed as well.

A note I didn't mention before: tasksOverlay-cz.xul is adapted from the tasksOverlay-ff.xul. The CDATA demarcators have been removed because I actually /want/ the entities to be evaluated in the preprocessing stage. This is the only way I can see to achieve this, although I may be missing something. Originally, for extra safety, another function placed outside the CDATA section was to return an object containing these entities, leaving the rest of the code inside the CDATA section. I ran across some weird behavior, though, using XULRunner 1.9.0.7 wherein CDATA sections appearing anywhere between the script tags effectively resulted in the JS not being evaluated.

Comment on attachment 382084 [details] [diff] [review] second time around, with tasksOverlay-cz.xul Can you add the new file with an hg copy then of the file you are using as the base so the diff is easier to read. This looks fine otherwise though.

Using git-style diffs to get Mercurial to diff against the original file.

Comment on attachment 382969 [details] [diff] [review] same as before, but diffing tasksOverlay-cz.xul against tasksOverlay-ff.xul >+ <script type="application/x-javascript" >+ src="chrome://global/content/viewSourceUtils.js"/> nit: application/javascript r=sdwilsh

Comment on attachment 382969 [details] [diff] [review] same as before, but diffing tasksOverlay-cz.xul against tasksOverlay-ff.xul Does this patch belong to bug 212754 perhaps? ;-)

(In reply to comment #16) > (From update of attachment 382969 [details] [diff] [review]) > Does this patch belong to bug 212754 perhaps? ;-) d'oh. I should read bugs when drilling through my review queue...

git diff against tasksOverlay-ff.xul

Comment on attachment 443630 [details] [diff] [review] correct patch, with menuitem specified in xul instead of created programmatically r=sdwilsh

Comment on attachment 443630 [details] [diff] [review] correct patch, with menuitem specified in xul instead of created programmatically >+ <overlaytarget id="scripts-overlay-target"> [The reindentation that this causes really messes up even a -w diff :-( ] >+ domiItem.parentNode.removeChild(domiItem); >+ jsc.parentNode.insertBefore(domiItem, jsc.nextSibling); [Don't need to remove the child; insertBefore already does that.]