Open Bug 715612 Opened 9 years ago Updated 3 years ago
creating the DOM for hidden tabs slows down browser startup
i'm seeing 3 - 5 second delays between when the browser window first appears (no content, 1 empty blank tab) and when all my app tabs and the rest of my tabs become visible. digging into it a bit, the delay is from when session restore creates all my tabs via tabbrowser.addTab(). in my session, i have 364 tabs, but only ~60 are in the active tab group. perhaps addTab should lazily create the DOM for hidden tabs, or something like that?
> perhaps addTab should lazily create the DOM for hidden tabs, or something > like that? addTab doesn't even know they're going to be hidden and even if it did, it would probably have to set them up in order to not confuse other code dealing with tabs.
Dao, do you have any ideas for how to reduce the amount of time involved in tab creation?
Depends on what exactly is taking time here. Presumably it's not just the DOM. Perhaps we could hide the tab bar before adding the tabs and show it afterwards?
Hm, interesting idea, thanks. Might result in a jumpy effect, but that's likely more desirable than multi-second non-responsive periods.
Temporarily hiding the tab bar while adding the blank tabs reduced the time from ~4 seconds to ~1.5 seconds consistently in my tests.
Interestingly, the tab bar stayed visible the entire time.
using .hidden gets us the win, but definitely breaks something. switching tabs is pretty broken after the restore. using .collapsed doesn't get us any win at all, but doesn't break anything.
errors when switching tabs after making tab bar hidden and then unhidden. Timestamp: 1/6/12 12:23:19 PM Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITypeAheadFind.setDocShell]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://browser/content/tabbrowser.xml :: updateCurrentBrowser :: line 907" data: no] Timestamp: 1/6/12 12:23:22 PM Error: newBrowser is undefined Source File: chrome://browser/content/tabbrowser.xml Line: 864 Timestamp: 1/6/12 12:23:23 PM Error: startTab is null Source File: chrome://global/content/bindings/tabbox.xml Line: 512
Another option would be to not add hidden tabs so eagerly in the first place. nsSessionStore.js would be in charge of this.
(In reply to Dão Gottwald [:dao] from comment #9) > Another option would be to not add hidden tabs so eagerly in the first > place. nsSessionStore.js would be in charge of this. Per the discussion in bug 681201, there could a major compat issue. It's not clear though that it is. I'm not familiar with how hidden tabs were implemented in tabbrowser though - are they reported by tabbrowser.tabs.length, etc?
Yes, for most purposes "hidden" tabs (those in other panorama groups) are only hidden visually, they're still in .tabs/.browers etc. .visibleTabs was a new property introduced to provide access to only visible tabs.
Some options: * about:unrestored - does even less than about:blank. tabbrowser handles it special, doing no navigation at all, just loading a src-less <browser>. might reduce problem, but won't resolve it. * lazy-load and lazy-create the actual tab containers, browsers, etc on access. that way the numbers report correctly, but the objects aren't created until used. requires mock versions of a bunch of tabbrowser properties. probably a rat's nest of complexity. * treat hidden tabs as non-existent in tabbrowser's public api. doesn't really break compat for some use-cases. surely does for others. but doesn't break code.
Dietrich is this a dupe of bug 681201?
(In reply to Taras Glek (:taras) from comment #13) > Dietrich is this a dupe of bug 681201? No. This is about startup time specifically, and about hidden tabs. That bug is about memory usage, and for unrestored tabs of any kind. That said, the work to fix one may affect the other.
(In reply to Dietrich Ayala (:dietrich) from comment #14) > (In reply to Taras Glek (:taras) from comment #13) > > Dietrich is this a dupe of bug 681201? > > No. This is about startup time specifically, and about hidden tabs. That bug > is about memory usage, and for unrestored tabs of any kind. > > That said, the work to fix one may affect the other. Feels like a dupe to me. Mike does mention startup lag in https://bugzilla.mozilla.org/show_bug.cgi?id=681201#c13
Marking it as a P2 in case you still think it's not a dupe.
Whiteboard: [snappy][ts] → [snappy:p2][ts]
This is about hidden tabs. Those that are hidden away in Panorama groups.
You need to log in before you can comment on or make changes to this bug.