Closed Bug 435906 Opened 13 years ago Closed 11 years ago

No overlay support in Chatzilla standalone on XULRunner for DOMi (DOM Inspector)

Categories

(Other Applications :: DOM Inspector, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wormsxulla, Assigned: crussell)

References

Details

Attachments

(1 file, 4 obsolete files)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Attached file chatzilla-specific overlay (obsolete) —
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.
Attachment #380739 - Flags: review?(sdwilsh)
Attachment #380739 - Attachment is patch: false
hg add should work just fine.  In cvs you could not do this unless you had commit access.
Attachment #380739 - Flags: review?(sdwilsh)
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.
Attachment #380738 - Flags: review?(sdwilsh)
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.
Attachment #380738 - Attachment is obsolete: true
Attachment #380739 - Attachment is obsolete: true
Attachment #382084 - Flags: review?(sdwilsh)
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.
Attachment #382084 - Flags: review?(sdwilsh)
Using git-style diffs to get Mercurial to diff against the original file.
Attachment #382084 - Attachment is obsolete: true
Attachment #382969 - Flags: review?(sdwilsh)
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
Attachment #382969 - Flags: superreview?(neil)
Attachment #382969 - Flags: review?(sdwilsh)
Attachment #382969 - Flags: review+
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? ;-)
Attachment #382969 - Flags: superreview?(neil) → superreview-
(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
Assignee: nobody → Sevenspade
Attachment #382969 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #443630 - Flags: review?(sdwilsh)
Comment on attachment 443630 [details] [diff] [review]
correct patch, with menuitem specified in xul instead of created programmatically

r=sdwilsh
Attachment #443630 - Flags: review?(sdwilsh) → review+
Attachment #443630 - Flags: superreview?(neil)
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.]
Attachment #443630 - Flags: superreview?(neil) → superreview+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.