2.04 KB, application/x-xpinstall
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20061204 Firefox/22.214.171.124 Creative ZENcast v1.02.12 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20061204 Firefox/188.8.131.52 Creative ZENcast v1.02.12 I was going to report a spoof/phish website and found that with DOM Inspector enabled, the "Report Broken Web Site..." and "Report Web Forgery..." menu items were missing from the Help drop-down. Disabling DOM Inspector in Add-Ons list and restarting Firefox has the items back on the Help drop-down. Re-enabling DOM Inspector and restarting has the items missing again. FWIW, other add-ons installed are Download Statusbar, DownThemAll!, FireFTP, Forecastfox, Google Browser Sync, Google Toolbar for Firefox, SearchStatus and Talkback. Reproducible: Always Steps to Reproduce: 1. Disable DOM Inspector and restart Firefox 2. Items return to Help drop-down 3. Enable DOM Inspector and restart Firefox 4. Items missing from Help drop-down again Actual Results: Help menu items disappear/reappear when DOM Inspector is enabled/disabled. Expected Results: Menu items shouldn't be connected to DOM Inspector being enabled.
That's probably a conflict between DOMi and one of your other extensions, since there's a few million people with DOMi enabled. Does it work if you disable everything but DOM Inspector? And if you then enable the others only one at a time, does it fail with just DOM Inspector plus one other?
Component: Toolbars → Extension Compatibility
QA Contact: toolbars → extension.compatibility
Good point...indeed, it looks like a conflict between DOMi and Download Statusbar. I enabled DOMi with each of the other add-ons I have (so only two were active at a time), and the menu items only disappeared with DOMi and Download Statusbar enabled together. Menu items are fine with only DOMi enabled. Menu items are fine with only Download Statusbar enabled. Menu items are fine with all except DOMi enabled. Menu items are fine with all except Download Statusbar enabled. Also, DOMi version is 184.108.40.206 and Download Statusbar version is 0.9.4.5.1.
Well, let's see if Devon's still using the same Bugzilla address he was using a couple of years ago (though you might have better luck with his forum at http://dlstatusbar.proboards43.com/ instead).
I also posted the problem at those forums, pointing to this Bugzilla thread. Thanks...
This is a rather bizarre set of circumstances. I've been able to fix it by moving some things around in my xul overlay file. I don't know why it fixed or why the combination of DOMi and downbar caused a problem in the Help menu in the first place. It should be ok in the next version of download statusbar. I think there is some weird xul parsing going on. Details: In my browser overlay I am adding a stringbundle to the main "stringbundleset" In simplistic terms, it was defined like: <overlay> <script/> <stringbundle/> <window id="main-window"/> </overlay> This worked fine, the translations in the string bundle work great. I changed it to: <overlay> <script/> <window id="main-window"> <stringbundle/> </window> </overlay> String bundle still works, and now DOMi and downbar seem to coexist without affecting the help menu. The reason I think there is some weird XUL parsing going on is that I could also fix the problem by adding an additional (and unnecessary) <script/> tag Like: <overlay> <script/> <stringbundle/> <window id="main-window"/> </overlay>
Oops, that last part should read: <overlay> <script/> <script2/> <stringbundle/> <window id="main-window"/> </overlay> This additional script tag didn't even need to point to a real file, but it 'fixed' the problem nonetheless.
Offhand, that certainly doesn't seem right. Now that you've done that much work on it, do you think you could attach a minimal testcase .xpi, just enough to trigger the bug?
Component: Extension Compatibility → XP Toolkit/Widgets: XUL
Product: Firefox → Core
QA Contact: extension.compatibility → xptoolkit.xul
Version: unspecified → 1.8 Branch
From my experience, putting id-less elements right under <overlay> has always worked weirdly. I fixed one code problem in bug 363419, but I'm not sure how it that fix affects this issue. Thanks for the analysis. I'll try to reproduce this later; a minimal testcase would indeed be much appreciated.
Hm. I can repro with 2.0.0.x, but not with a trunk build. Can you reproduce on trunk?
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.