Closed Bug 435906 Opened 13 years ago Closed 11 years ago
No overlay support in Chatzilla standalone on XULRunner for DOMi (DOM Inspector)
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
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 - Attachment is patch: false
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 18.104.22.168 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.
Attachment #382084 - Attachment is obsolete: true
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
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.