[ext] Add-ons Manager Dialog for FF4 (no restart*)

[Jack Black]

• Looks like there are conflicts with:
  
  
  • Redirector: when called from the Add-ons Manager, its Settings page doesn't open in a new browser tab while it should, and the dialog itself is too small and since it isn't re-sizable it's harder to manage.
  • Redirect Cleaner: the "OK" button from the options dialog doesn't work, when the latter is invoked from the add-ons manager.

• the back and forward mouse buttons don't work in the Dialog.

• It is possible to have two instances of the Add-ons Manager: if your add-on is disabled and the only window/tab opened is about:addons, then enabling your add-on duplicates the manager

• It seems any keyboard shortcut won't work.

(v1.2.1 on WIN 7 x86 SP1 with Firefox 14.0.1).

[Morten79]

... the Dialog always displays the last selected pane (besides, of course, the "Get Add-ons" one), no matter if it is called from another add-on (e.g. Scriptish).
For example, if you open up the dialog, select the Plug-In pane, close the dialog, then click on Scriptish's "Manage User Scripts...", the dialog will open on the Plug-In pane instead of the User Scripts one.

I can confirm what Jack Black have said. The Add-ons manager will always display the last selected pane. The same is true for Greasemonkey. It's not a big issue just a little annoying. Please try too fix this soon.

[avatar.ds]

Version 1.2.3 is fully reviewed on AMO and available for automatic update now.
- Add compatibility with Addons Manager Hilite extension (experimental).
- Make the dialog respect direct AOM pane selection when opening (again).
- Cumulative compatibility updates for Firefox 16-18.

Tested with Stylish and Greasemonkey, and should work again with both no problem. Sorry it took so long to fix.

[avatar.ds]

• Looks like there are conflicts with:
  
  • Redirector: when called from the Add-ons Manager, its Settings page doesn't open in a new browser tab while it should, and the dialog itself is too small and since it isn't re-sizable it's harder to manage.

Yes, I see this nuissance... I'll try to investigate this but it may be non-trivial to fix due to some intricate hacks I had to introduce in the dialog in order for other url-opening requests (i.e. from the discovery pane and addon descriptions) to work the way they do now. Running AOM in a dialog makes it extremely unfriendly towards links, and this maybe one manifestation of that problem.

• Redirect Cleaner: the "OK" button from the options dialog doesn't work, when the latter is invoked from the add-ons manager.

It actually does work (i.e. checkbox settings get applied and stay checked thereafter), but it doesn't close the dialog for some reason... This looks very weird and I don't even know where to look to address this, but I'll keep this bug on my radar.

• the back and forward mouse buttons don't work in the Dialog.

Good catch. I don't use these so I never stumbled on this bug before.

• It is possible to have two instances of the Add-ons Manager: if your add-on is disabled and the only window/tab opened is about:addons, then enabling your add-on duplicates the manager

Nice catch This possibility kind of escaped the logic I invented for killing Add-ons Manager tab. If there are several windows and AOM is the only tab in one of them, the tab gets killed and the window automatically closes. But if it's the only such window, then oops - obviously, I had to intentionally prevent closing the last browser window, so that the application remains usable, which means the Add-ons Manager tab will stay opened. I don't think this is very important bug, but I could special-case this scenario to open a default home page. Or maybe even make this behaviour default for any browser window irrespective of their number.

• It seems any keyboard shortcut won't work.

Hmm... I remember they didn't work for me once or twice, but this problem was so rare and evasive I couldn't even properly investigate it. 99.9% of the time shortcuts seem to work fine for me. If you still experience this bug, I could use your help to catch it.

[avatar.ds]

OOPS!

Sorry for the quirky upgrade. Apparently this time AMO did not like it when I tinkered with compatibility data for the addon in my AMO dashboard and decided to kindly update FF18 users to a package formally marked internally as incompatible! Sorry for the inconvenience, the addon should hopefully be automatically downgraded back to old version now. It's no big deal as v1.4's main idea is compatibility with FF20.

[avatar.ds]

Version 1.4.1 is now available on AMO and should be automatically downloaded to users of Firefox 18 as an apdate to both versions 1.2.3 and 1.4. It resolves the bug that forced Firefox 18 to assume version 1.4 was compatible but then immediately disable it after an update due to formal criteria. Version 1.4 has been pulled off AMO due to that bug. These two latest versions are identical otherwise and are designed to be compatible with current pre-release versions of Firefox.

[custom.firefox.lady]

Found this issue while testing compatibility with my beta version of [Edit: fixed name of extension] Addons Manager Hilite (no worries there,Addons Manager Hilite 2.0b3 will handle that):

Steps to reproduce:
Install Add-ons Manager Dialog Returns into clean profile
Navigate to about:compartments
Close other open tabs, if any
Open Add-ons Manager (App button > Add-ons)
Find "about:addons" on the about:compartments page
Open and close Add-ons Manager multiple times
Refresh the about:compartments page

Result: the number of "about:addons" items listed in about:compartments increases and remains even when Add-ons Manager is closed (until fx restart).
Expected: "about:addons" disappears from about:compartments after closing AoM and refreshing about:compartments.

(Tested with 1.4.1 on fx 19.0)
See https://developer.mozilla.org/en-US/doc ... mpartments

[avatar.ds]

Found this issue while testing compatibility with my beta version of Stay-Open Menu (no worries there, Stay-Open Menu 2.0b3 will handle that):

Steps to reproduce:
Install Add-ons Manager Dialog Returns into clean profile
Navigate to about:compartments
Close other open tabs, if any
Open Add-ons Manager (App button > Add-ons)
Find "about:addons" on the about:compartments page
Open and close Add-ons Manager multiple times
Refresh the about:compartments page

Result: the number of "about:addons" items listed in about:compartments increases and remains even when Add-ons Manager is closed (until fx restart).
Expected: "about:addons" disappears from about:compartments after closing AoM and refreshing about:compartments.

(Tested with 1.4.1 on fx 19.0)
See https://developer.mozilla.org/en-US/doc ... mpartments

Thanks for the catch.

There must be a minor leak somewhere. A few "tiny" things get multiplied in about:memory when the dialog is opened. I had a brief look at it and it appears it goes away if the addon is disabled (without restarting FF).

I went to great lengths to ensure the addon does not leak when disabled, but I didn't expect any such issues at run time. I'm sure it's nothing critical but leaks are ugly, so I'll keep digging for it.

Confirmed.

[custom.firefox.lady]

If both Add-ons Manager Dialog Returns and my Addons Manager Hilite 2.0 (currently in beta) are installed, the aomhilite.xml file gets leaked and shows as a zombie compartment (in about:ccdump). For now, I'll assume it's caused by whatever is causing the Add-ons Manager Dialog Returns leak you confirmed. aomhilite.xml is only a 1kb file, so this should not be a major issue.

[avatar.ds]

If both Add-ons Manager Dialog Returns and my Addons Manager Hilite 2.0 (currently in beta) are installed, the aomhilite.xml file gets leaked and shows as a zombie compartment (in about:ccdump). For now, I'll assume it's caused by whatever is causing the Add-ons Manager Dialog Returns leak you confirmed. aomhilite.xml is only a 1kb file, so this should not be a major issue.

I also notice that compartments for about:blank grow the same way when the dialog is opened without getting destroyed until addon is shut down. My guess is this might have something to do with intercepting the about:addons url, perhaps Firefox creates a new tab each time for about:addons and when my addons intercepts this it doesn't remove some internal traces of those things completely... I'll have to dig through my code to see what actually happens.

Thanks for referring me to about:ccdump, I never knew before about its existence!

[Jack Black]

• Looks like there are conflicts with:
  
  • Redirector: when called from the Add-ons Manager, its Settings page doesn't open in a new browser tab while it should, and the dialog itself is too small and since it isn't re-sizable it's harder to manage.

Yes, I see this nuissance... I'll try to investigate this but it may be non-trivial to fix due to some intricate hacks I had to introduce in the dialog in order for other url-opening requests (i.e. from the discovery pane and addon descriptions) to work the way they do now. Running AOM in a dialog makes it extremely unfriendly towards links, and this maybe one manifestation of that problem.

I just spotted another add-on that seems to be affected by such bug, but with more dramatic results: upon trying to open Ghostery 5.3.2's options dialog (that normally opens in a tab) from about:addons, the options window will open, but with a size of 1px by 1px!
Then Add-ons Manager Dialog Returns won't let you just close about:addons: you first have to close Ghostery's dialog... but there is only a tiny space (only a few pixels wide) where you can really interact with the close button, making it harder to exit (at first I thought that about:addons was frozen and that I wouldn't be able to do anything besides restarting Firefox).

Here's an excerpt (pertaining to Ghostery) from the log when this bug occurs:

Exception { message: "", result: 2147746065, name: "NS_ERROR_NOT_AVAILABLE", filename: "resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///C:/Users/BlackJack/AppData/Roaming/Mozilla/Firefox/Profiles/wtf.default/extensions/firefox@ghostery.com.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://firefox-at-ghostery-dot-com/ ... /button.js", lineNumber: 60, columnNumber: 0, inner: null, data: null, location: XPCWrappedNative_NoHelper }

For the record, when trying to open the options of S3.Menu Wizard from about:addons, a similar 1-pixel-large dialog opens up, but it quickly closes to be opened in a tab (just like the default behavior).
I have not yet checked how Add-ons Manager Dialog handle opening addon's options dialog, nor how these 2 particular add-ons try to open their respective dialogs (safe for the fact that one uses a resource:// URL to open a html, and the other a chrome:// URL to open a XUL), but it could help in finding a workaround for the aforementioned problematic add-ons...

[caseih]

Is there a bug tracker for this add-on?

There seems to be a serious memory leak in Add-ons Manager Dialog Returns add-on. I'm running FF 24 ESR, and also PaleMoon 24.7 under Linux and both exhibit this behavior. After a couple of days of running (not even opening the add-ons dialog), the add-ons memory usage addon reports over 1 GB of memory usage by the Add-ons Manager Dialog. This is with Add-ons Manager Dialog Returns v 1.4.1. Something seems fishy to me. Should be easily reproducible. Just run FF for a few days and check the results of the addons-memory add-on.

[-ck-]

Looks like this finally stopped working with the newest FF36

Any chance of an update?

[Kevin McFarlane]

Yes, I too have just spotted this.

[XTAL256]

No longer works with Pale Moon 27.