Style to-be-restored tabs

NEW
Unassigned

Status

()

Firefox
Theme
8 years ago
7 years ago

People

(Reporter: zpao, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Limi asked about this via email but I figured we could just put it in bug.

BarTab styles it to-be-restored tabs with a simple opacity. Not sure if we want to have some sort of visual indication that a tab hasn't been fully restored yet, but I'll leave it up to UX.

The rules BarTab uses wouldn't be the same, but for the sake of sharing:
http://github.com/philikon/VerticalTabs/blob/master/skin/osx/osx.css#L60-63

We can't match [busy] because the tabs won't have that attribute, but I do set __SS_needsRestore (on tab.linkedBrowser). So we'd need to do something extra on the session restore side.
Yes, I think reducing the opacity of tabs that haven't been loaded yet (or an equivalent indicator) is useful, at least in the "hidden bartab" behavior.

Not sure it's needed for the cascading restore, but if it's hard to separate them, I'd prefer it on both as opposed to not having it on any of them.
I'm pretty sure we don't want to do this for cascading restore, as it would cause a bunch of jitter/noise in the UI on update, and all those tabs should load up quickly enough (within 3 minutes) such that it only matters in a minority of cases where someone's starting up their browser in order to load a bunch of saved tabs so they can then disconnect from the network and I know people do that but oh my god it's not the primary use case so let's not and say we didn't.

For the bartab case is nice, though!
I agree with Mike, I'm worried that in addition to progress bars and app tab notifications, if we also style unloaded tabs Firefox on load is going to light up like a Christmas tree.
You need to log in before you can comment on or make changes to this bug.