If there is a language add-on installed, there is a noticeable delay between when the list of categories is first shown, and when the "Language" category is shown. This delay exists because the "Language" category should not be visible if there are no language packs installed (Bug 553483). The delay should be made less noticeable.
Only show the list of categories after the hidden state for the Language and Search Engine categories is determined.
Assignee: nobody → bparr
Status: NEW → ASSIGNED
Attachment #456815 - Flags: review?(dtownsend)
Is that also flexible enough to make sure it behaves the same way for add-ons which overlay the add-ons manager and bring their own categories?
Henrik, that should not be a problem. Assuming that the add-on added the category to the "categories" richlistbox, their category will be shown at the same time as the built-in categories.
Depending on if that will also happen lazily. Lets say Greasemonkey will add its own category only, if scripts are really installed. Otherwise it will also be hidden.
Exposed variable and function to make it very easy to do what Henrik described in comment 4. Steps: 1) Add onload listener to window object 2) When the onload listener is called, do "gCategories.pendingCategories++;" so that gCategories knows to wait for another category to initialize 3) Do work (possibly asynchronous work) to initialize category 4) Call "gCategories.notifyCategoryInitialized();" to let gCategories know that the category is initialized
Thanks Ben! I wonder which parts can be automatically tested.
Added a mochitest that tests that the category list only shows after all categories have initialized.
I think there is a better/simpler way to handle this bug. Instead of holding off showing the categories every time the Add-ons Manager is loaded, we could just persist the hidden state of the language category. So, basically all the time, there will not be a delay. There will still exist a delay when the user goes from not having language packs installed to having language packs installed, and vice versa. However, since this will happen very very rarely, it should be fine. The main benefit of this different way is simplicity, but it also means that initially showing the list of categories will be slightly faster (not waiting for asynchronous calls to finish). Overlaying the list of categories would be just like any other overlay that adds a richlistitem to a richlistbox, so no problems there.
Uses persist approach described in comment 8. Therefore, it depends on Bug 571598. Also, the test depends on Bug 578580.
Comment on attachment 457256 [details] [diff] [review] Patch and Test (new approach) This is an elegant solution, nice work. Since it depends on the other bug though I'm going to hold off reviewing it till after beta 2 madness is over
Updated test so it works with the landed patch for Bug 578580.
Update patch now that Bug 571598 has been fixed.
Attachment #461491 - Flags: review?(dtownsend) → review+
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b4
Verified with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b4pre) Gecko/20100813 Minefield/4.0b4pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.