creating the DOM for hidden tabs slows down browser startup

NEW
Unassigned

Status

()

Firefox
Tabbed Browser
6 years ago
2 years ago

People

(Reporter: dietrich, Unassigned)

Tracking

(Blocks: 2 bugs)

unspecified
x86
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [snappy:p2][ts])

(Reporter)

Description

6 years ago
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?
(Reporter)

Updated

6 years ago
Whiteboard: [snappy][ts]
(Reporter)

Updated

6 years ago
Blocks: 582005
> 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.
(Reporter)

Comment 2

6 years ago
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?
(Reporter)

Comment 4

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

Comment 5

6 years ago
Temporarily hiding the tab bar while adding the blank tabs reduced the time from ~4 seconds to ~1.5 seconds consistently in my tests.
(Reporter)

Comment 6

6 years ago
Interestingly, the tab bar stayed visible the entire time.
(Reporter)

Comment 7

6 years ago
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.
(Reporter)

Comment 8

6 years ago
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.
(Reporter)

Updated

6 years ago
Blocks: 669034
(Reporter)

Comment 10

5 years ago
(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.
(Reporter)

Comment 12

5 years ago
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

5 years ago
Dietrich is this a dupe of bug 681201?
(Reporter)

Comment 14

5 years ago
(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

5 years ago
(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

5 years ago
Marking it as a P2 in case you still think it's not a dupe.
Whiteboard: [snappy][ts] → [snappy:p2][ts]
(Reporter)

Comment 17

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

Updated

3 years ago
Flags: firefox-backlog?

Updated

3 years ago
Flags: firefox-backlog? → firefox-backlog-
You need to log in before you can comment on or make changes to this bug.