715612 - creating the DOM for hidden tabs slows down browser startup

Status: NEW

(Firefox :: Tabbed Browser, defect)

Description

[Dietrich Ayala (:dietrich)]

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?

Comment 1

[Dão Gottwald [:dao]]

> 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.

Comment 2

[Dietrich Ayala (:dietrich)]

Dao, do you have any ideas for how to reduce the amount of time involved in tab creation?

Comment 3

[Dão Gottwald [:dao]]

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?

Comment 4

[Dietrich Ayala (:dietrich)]

Hm, interesting idea, thanks. Might result in a jumpy effect, but that's likely more desirable than multi-second non-responsive periods.

Comment 5

[Dietrich Ayala (:dietrich)]

Temporarily hiding the tab bar while adding the blank tabs reduced the time from ~4 seconds to ~1.5 seconds consistently in my tests.

Comment 6

[Dietrich Ayala (:dietrich)]

Interestingly, the tab bar stayed visible the entire time.

Comment 7

[Dietrich Ayala (:dietrich)]

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.

Comment 8

[Dietrich Ayala (:dietrich)]

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

Comment 9

[Dão Gottwald [:dao]]

Another option would be to not add hidden tabs so eagerly in the first place. nsSessionStore.js would be in charge of this.

Comment 10

[Dietrich Ayala (:dietrich)]

(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?

Comment 11

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 12

[Dietrich Ayala (:dietrich)]

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.

Comment 13

[(dormant account)]

Dietrich is this a dupe of bug 681201?

Comment 14

[Dietrich Ayala (:dietrich)]

(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.

Comment 15

[(dormant account)]

(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

Comment 16

[(dormant account)]

Marking it as a P2 in case you still think it's not a dupe.

Comment 17

[Dietrich Ayala (:dietrich)]

This is about hidden tabs. Those that are hidden away in Panorama groups.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 24 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 19

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.