Open Bug 1064962 Opened 5 years ago Updated 5 years ago
Add auto-refresh to session restore data schema
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140825202822 Steps to reproduce: Firefox's lazy session restores have created numerous user unfriendly issues, In particular tabs that auto-refresh before session restore do not do so afterwards. This is problematic for users who expect, and should have no reason not to expect, auto-reloading on tabs after session restore. My better half as an example, she's a reasonably tech savvy person, though she likes to run with a LOT of tabs open (100+) and at least 1/6th of them are auto-reloading. After lazy loading was introduced she could not figure out why her gmail tab, RSS reader tabs, live reddits, etc were not showing the correct information (ie: new gmail message comes in, it updates the title). It ends up that she would close firefox, use session restore later, and not understanding the difference between normal and lazy loading, she assumed her tabs would behave as they always did. Ever since she spends 5 minutes every morning clicking each of these tabs to make sure it reloads properly. A simple addition to the stored session information which flags a tab for non-lazy loading on restore would fix this while generally maintaining lazy loading. Ideally, any tab that has a meta refresh tag or window.location or that has refreshed without user action or that is manually set via tab context menu. This should not circumvent accessibility.blockautorefresh = true but should save previous decisions since it is restoring the previous session.
Severity: normal → enhancement
Component: Untriaged → Session Restore
OS: Windows 8.1 → All
Hardware: x86_64 → All
See Also: → 801748
I would hate that. After session restore, Firefox is snappy. Thanks to lazy loading of tabs. An self-reloading tab has no privilege to break that. The behaviour asked here by Jimmy is little probable. But it could be an optional thing. Or there could be some little red dot on those tabs, meaning "Click me and I will reload myself as I was doing before."
User friendliness > snappiness until snappiness interferes with the average user experience. In this case, based on Mozilla data, the average user would only have 0-3 tabs reloading which would not significantly affect "snappiness". Even in the extreme case I exampled we're only talking 16-20 tabs. Since they would be identified already they could also be loaded in a staggered manner to prevent slowdowns. As to a red dot, something like that is meaningless to a user who doesn't know what it's meant to represent. Can you explain what you mean by "little probable"?
You need to log in before you can comment on or make changes to this bug.