User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130307075451
Steps to reproduce:
Some of us prefer the old way of displaying the addon manager in its own dialog instead of another tab. You can do this by calling Firefox from the command line as follows: "firefox -chrome about:addons"
(alternatively, replace "about:addons" with "chrome://mozapps/content/extensions/extensions.xul" – I guess this is the more correct way, though it doesn't affect this bug)
Firefox will open the addon manager, but the addon list (on the right) will either display a loading indicator or simply stay blank (white) indefinitely. This happens regardless of which category (addons, plugins, themes etc.) is initially selected.
The only way to get the list to show up is by clicking any category label, even the selected one.
Just like when opening the addon manager normally (through the menu or with about:addons), the initially selected category should load the addon list immediately.
I can reproduce this with Ubuntu. Loading dialog will be displayed when using "firefox -chrome about:addons" until selecting any category.
Reproducible on Firefox 10 as well.
I was looking into this.
When I tried the same thing, I got this in my console :
That was because window.arguments was being null.
So, some necessary arguments are not being passed into the new addons manager window created.
Is an openDialog call bringing the new window up?
If someone can guide me further, I could take this up.
Thanks, Sachin :)
In that case, we just need an additional check on that line to ensure window.arguments is an object, but also isn't null.
I wouldn't worry about tracing where the values of window.arguments is coming from. Opening things via the -chrome command line flag is a bit weird, and ancient code - changing that would likely break other things. Instead, we should just have better checks in the Add-ons Manager to ensure the inputs are what we expect.
I also wouldn't worry about adding an automated test for this, as opening it via the -chrome flag isn't something we support (but it'd still be nice to fix, especially since it looks like it'll be an easy fix).
Created attachment 740065 [details] [diff] [review]
Verfifies that windows.arguments is not null
It works now.