Closed Bug 562933 Opened 15 years ago Closed 5 years ago

Add-ons manager waits until other tabs have finished loading before displaying after session restore

Categories

(Toolkit :: Add-ons Manager, defect, P3)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: Peter6, Unassigned)

References

(
URL
)

Details

(Whiteboard: [AddonsRewriteTestday][rewrite])

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100430 Minefield/3.7a5pre ID:20100430040256 repro: open FF open a few pages in tabs open add-ons manager close FF reopen FF result: the other pages load and display before add-ons manager expected: add-ons manager to load and display first
Whiteboard: [AddonsRewriteTestday][rewrite]
How long is the delay for you and how many tabs you have open?
a few tabs open, http://tinderbox.mozilla.org/Firefox/ is one of them which takes 15 secs on avg to load. So in this case, 15 secs delay.
Ah right. Now I can see it. The left pane is drawn immediately while the list view takes that amount of time to load. Steps: 1. Open http://tinderbox.mozilla.org/Firefox/ in a tab 2. Open the Addons Manager in another tab 3. Restart Firefox Paul, could this be related to our Network Prioritization work? Or is this definitely an issue with the new add-ons manager?
Blocks: 550048
URL: http://tinderbox.mozilla.org/Firefox/
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Hmm, I guess that's possible. If so, it would be because about:addons is creating it's own browser object (which does happen) and that doesn't inherit the priority. Though the browser should be created with normal priority and the background tabs in the focused window would be at the same priority level. So the only reason it would be blocking is if it's already saturating the number of network connections, which doesn't seem likely. And assuming this is the case, this should only hold true for when about:addons is loading AMO.
This may or may not be related to bug 553771.
(In reply to comment #5) > This may or may not be related to bug 553771. Opening the Addons Manager after all pages have been loaded, the extensions are shown immediately. So I think that bug 553771 is not the reason for this behavior.
next test open FF have one blank tab opened create a set of bookmarks is a folder, the first bookmark is about:addons click on the folder and select [open all in tabs] result: the first tab (about:addons) is displayed AFTER all the other tabs are loaded.
Hmm, I can't reproduce using either of those steps. Even if about:addons is in a tab that isn't focused and therefore should have lower network prioritization, it still loads first.
Blair, it's not about the tab itself, but the right pane. The list of extensions, themes, or any other add-on type is shown first after all other tabs have been finished loading. This is reproducible for me with each restart I have to do.
After playing around and trying to get a screencast, I'm no longer able to see this issue. :/ It has been stopped magically for me. Peter, can you still see it in a fresh profile? A good set of STR would be really helpful.
(In reply to comment #10) > After playing around and trying to get a screencast, I'm no longer able to see > this issue. :/ It has been stopped magically for me. Peter, can you still see > it in a fresh profile? A good set of STR would be really helpful. My computer died Henrik, so someone else will have to verify this
I guess this bug deserves a change in Summary but I'm not sure how exactly to formulate it. I've also obseved this "right-pane slowness" in SeaMonkey 2.1a2pre (cf. bug 561600 comment #34), even when all my other tabs had finished loading and I opened about:addons (or chrome://mozapps/content/extensions/extensions.xul which amounts to the same thing but is downward-compmatible) or even when switching from Extensions to Themes or vice-versa. This was my usual profile (40 extensions or thereabouts); I'll test later today with a newly created profile.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100517 SeaMonkey/2.1a2pre Built from http://hg.mozilla.org/mozilla-central/rev/18ab62104d9a (and I don't know the comm-central revision or the hhmmss build time). On a freshly created profile, I don't really notice right-pane slowness, but of course there are only three, then four extensions displayed (Javascript debugger, DOM Inspector and Chatzilla; then Debug/QA UI after going to Themes and back) and two themes (Default and Modern). I bet Firefox would have even fewer of them out of the box. There are more plugins (five, and the default plugin is not included), and when going to the Plugins tab, right-pane slowness begins to be noticeable (a few seconds) but not yet annoying. I suppose that the number of entries plays a role -- and yet with such large type there is only room for four and a half of them within view, much fewer than in the former EM where I could see, how many? Ten? Twelve? But in the older EM the contents part did not become conspicuously blank before getting rendered. In my day-to-day profile I had until recently 30 extensions enabled and 12 disabled (see attachment 444727 [details]) but I have uninstalled some of the more obnoxious disabled ones after I noticed that they all got enabled by this new extension manager. I don't think this is "unreasonably many" for production use (as opposed to debugging) -- and testing under real-life conditions will have to begin sooner or later, IMHO preferably sooner.
(In reply to comment #12) > I guess this bug deserves a change in Summary but I'm not sure how exactly to > formulate it. > > I've also obseved this "right-pane slowness" in SeaMonkey 2.1a2pre (cf. bug > 561600 comment #34), even when all my other tabs had finished loading and I > opened about:addons (or chrome://mozapps/content/extensions/extensions.xul > which amounts to the same thing but is downward-compmatible) or even when > switching from Extensions to Themes or vice-versa. This was my usual profile > (40 extensions or thereabouts); I'll test later today with a newly created > profile. As I understood it, this bug is about loading AMO (the 'get extensions' section) in the right pane, not about loading the extensions/themes section. As for slowness showing extensions/themes, I don't find this surprising. The new EM APIs are async, so if there are a lot of extensions to show, I would expect content to come in async, though it shouldn't take long. The old EM was sync, so rendering was probably blocked on loading the list of extensions & their info.
(In reply to comment #14) > As I understood it, this bug is about loading AMO (the 'get extensions' > section) in the right pane, not about loading the extensions/themes section. > > As for slowness showing extensions/themes, I don't find this surprising. The > new EM APIs are async, so if there are a lot of extensions to show, I would > expect content to come in async, though it shouldn't take long. The old EM was > sync, so rendering was probably blocked on loading the list of extensions & > their info. no, this is about displaying the installed extensions, in my case there are just a few.
(In reply to comment #15) > no, this is about displaying the installed extensions, in my case there are > just a few. Correct. Any loading we are talking about is locally.
Summary: about:addons should load/display first if it is the current page → Add-ons manager waits until other tabs have finished loading before displaying after session restore
I can't reproduce this, other tabs are still loading after the add-ons manager has appeared for me.
(In reply to comment #17) > I can't reproduce this, other tabs are still loading after the add-ons manager > has appeared for me. I see Peter van der Woude's unnerving delay (comment #15) with 30 or 40 extensions but not with (in a SeaMonkey nightly) the four built-in ones, so Paul O'Shannessy's sync/async explanation (comment #14) explains a lot of it.
I just saw this for the first time. I switched panes, and back again (not quickly - after a couple of seconds) to the Extensions pane - eventually the list was populated, but with two of every item (ie, bug 562899). So it looked like AddonManager.getAddonsByType() had been called but was taking ages to call the callback. Is there anything that could be making the DB access abnormally slow here?
Nothing I can think of. I know that all the DB accesses should be asynchronous, Shawn, do we have one async thread per connection or one shared for all connections?
(In reply to comment #20) > Nothing I can think of. I know that all the DB accesses should be asynchronous, > Shawn, do we have one async thread per connection or one shared for all > connections? One per connection.
Not reproducible here with Firefox 55.0.3 (64-bit) on FreeBSD. Tested with browser.sessionstore.restore_on_demand true (the default). ---- FreeBSD 12.0-CURRENT #0 r320869: Mon Jul 10 13:57:55 UTC 2017 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC # pkg info firefox | grep -i version Version : 55.0.3_1,1 #
… I forgot to mention: - 97 extensions enabled (105 according to about:healthreport) - 127 extensions disabled - multiprocess disabled (by some of the extensions that are enabled).
Priority: -- → P3
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.