Closed Bug 1193386 Opened 10 years ago Closed 10 years ago

Wrong tab selected after restoring the browser

Categories

(Firefox for iOS :: Browser, defect)

All
iOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bnicholson, Assigned: bnicholson)

Details

Attachments

(1 file)

STR: 1) Open a new tab. 2) Select another tab. 3) Close and reopen the browser. After these steps, the tab from step 1 is selected. We should flush the session when the selected tab changes.
Attachment #8646428 - Flags: review?(sleroux)
Attachment #8646428 - Flags: review?(sarentz)
I see that this will fix the bug, but it'll also do a full DB write and a full session store flush, with thumbnails, every time you switch tabs. That seems like a bad idea. Can we just not persist isSelected in SavedTab, and instead aggressively persist an index in `prefs`?
(In reply to Richard Newman [:rnewman] from comment #2) > I see that this will fix the bug, but it'll also do a full DB write and a > full session store flush, with thumbnails, every time you switch tabs. That > seems like a bad idea. > > Can we just not persist isSelected in SavedTab, and instead aggressively > persist an index in `prefs`? A couple points worth noting: 1) Selecting a tab is relatively infrequent operation versus loading a new URL. We already call storeChanges in the latter case. 2) storeChanges is much less expensive with bug 1187176 fixed. Right now, storeChanges actually stores the selected tab as a boolean on the SavedTab, rather than an index. This is slightly safer since we don't need to worry about the index getting out of sync for whatever reason (i.e., one of the tabs has no history and is skipped). It also feels a bit messy to have our session data spanned across three sources: the keyed archive, screenshots on disk, and now an index in prefs. Also worth noting that we do a full session flush for each of these events (and more!) on Android. I forgot about the DB flush, though. So how do you feel about a bool passed to storeChanges that allows us to bypass the `self.profile.storeTabs` call?
Flags: needinfo?(rnewman)
> 1) Selecting a tab is relatively infrequent operation versus loading a new > URL. We already call storeChanges in the latter case. Yeah, but we also do the thumbnail -> browser zoom at the same time on switch, so anything we can do to save cycles is worth it. > 2) storeChanges is much less expensive with bug 1187176 fixed. Yup. > Right now, storeChanges actually stores the selected tab as a boolean on the > SavedTab, rather than an index. This is slightly safer since we don't need > to worry about the index getting out of sync for whatever reason (i.e., one > of the tabs has no history and is skipped). Yup, I quite agree. > I forgot about the DB flush, though. So how do you feel about a bool passed > to storeChanges that allows us to bypass the `self.profile.storeTabs` call? I'd split it into two methods (one of which depends on the other) and just call the one you want. This gets even better if we don't store thumbnails -- I don't mind at all if we write an updated set of open tabs, so long as we're not writing thumbnails or touching the DB!
Flags: needinfo?(rnewman)
(In reply to Richard Newman [:rnewman] from comment #4) > This gets even better if we don't store thumbnails -- I don't mind at all if > we write an updated set of open tabs, so long as we're not writing > thumbnails or touching the DB! Yeah, we only write thumbnails that have changed, so there won't be many thumbnail writes. We should flush new thumbnails, though, because they're generated only when going to the tab tray. If we don't save them here, the screenshot from the previous tab may not be persisted at all.
Updated.
Attachment #8646428 - Flags: review?(sleroux) → review+
Attachment #8646428 - Flags: review?(sarentz)
Attachment #8646428 - Flags: review?(rnewman)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: