While setTab does end up setting the label and icon, it also does completely different and more crucial things. This call really doesn't belong in updateTabLabelAndIcon.
MozReview-Commit-ID: 9HXYS0fXgRN
restoreWindow only opens new tabs rather than re-use pre-existing tabs, so
there's no point in calling showTab anymore. hideTab also will not hide the
selected tab, so the "all tabs to be restored are hidden" case can't happen.
MozReview-Commit-ID: FzmRcjprkuN
This patch replaces FX_SESSION_RESTORE_CONTENT_COLLECT_DATA_LONGEST_OP_MS with
a more fine-grained data collection via a keyed histogram so that we can
determine which type of data collection we spend a lot of time on.
Additionally, it abandons sending telemetry data from the content to the parent
via custom messages and instead uses the Telemetry service directly. Thus it
also gets rid of a bug that currently overrides measurements for the same
histogram done quickly in succession
FX_SESSION_RESTORE_COLLECT_DATA_LONGEST_OP_MS can go because that's exactly the same as FX_SESSION_RESTORE_COLLECT_DATA_MS now.
We can remove FX_SESSION_RESTORE_COLLECT_COOKIES_MS because that's just a flat line since bug 912717 landed.
Opening pages in a new tab might suffer an extra delay from e10s-multi because
the new process has to start up and then run all the process / frame scripts
before it can react on the request from the parent to load the first page.
There are two code paths. Either we start the tab with a remote browser and
then the RemoteWebNavigation will send the request. Or we start with a non-remote
browser and have to change the remoteness flag on it, and then the SessionStore
will send the request.
In each cases we start the timer on the parent side, send it with the message,
and when the child receives it it stops the timer and reports the measured delay.
Since bug 912717 the cookies moved from state.windows[x].cookies (i.e. stored
per-window) to state.cookies (i.e. one global list of cookies). We forgot to
update the code in SessionSaver._saveState() that purges cookies upon clean
shutdown if requested by the user's preferences.
Bug 588482 made it possible to restore pinned tabs in windows before restoring the rest of the
tabs. Part of this involves extracting the pinned tab data from the last session, and make it
the default state to restore. The rest can be restored later.
If one of the pinned tabs in a window were selected, the code that was preparing the default
state for that window set the selection value by calculating the length of the tabs array
(before adding the selected one), and adding 2. Presumably, 1 count is because of the tab
we're about to add, and another count is due to how the "selected" value in SessionStore
is 1-indexed (where "0" means, "don't change the selection").
This is an off-by-one error though, since the tabs array length already cancels out the
need for the extra "1-index" difference. It is sufficient to just add 1 to the length of
the tabs array to calculate the selected value.
This appears to have been a bug for a while, but was covered up by the fact that the old
tab selection code exited early if the 0-indexed value of the selected tab was not within
the length of the tabs array. Bug 1351677 uncovered this bug by removing that second check.
This patch fixes the off-by-one error, and also puts a check back in to ensure that the tab
we're going to select is at a valid index.
MozReview-Commit-ID: 9WbbU0vUJHG
