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
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.
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 a LayoutHistoryState is basically just a collection of PresStates, we just save each PresState we can find and then later restore it.
MozReview-Commit-ID: A6WpdelseHn
--HG--
extra : rebase_source : 21c2929ed64ff5ef046ea65664af78cdad517786
This helps differentiate restorations that were caused by navigateAndRestore, as opposed
to SessionStore having set state via setBrowserState, setWindowState, or setTabState.
MozReview-Commit-ID: DEEbKLh7f7p
--HG--
extra : rebase_source : c48ab225d17128041ccbde4e5cc8c87899166b9e
This helps differentiate restorations that were caused by navigateAndRestore, as opposed
to SessionStore having set state via setBrowserState, setWindowState, or setTabState.
MozReview-Commit-ID: DEEbKLh7f7p
--HG--
extra : rebase_source : 7fa68acf1ffd85f28af2be9c00f2ef65b21375f6
We want to use this for Android, too. Once again, moving the file necessitates fixing a few ESLint errors that weren't yet checked for under the old directory.
MozReview-Commit-ID: IPxcizKwzAX
--HG--
rename : browser/components/sessionstore/SessionHistory.jsm => toolkit/modules/sessionstore/SessionHistory.jsm
extra : rebase_source : 77a85942443026620c77508d6ccb405e0a9864ff
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
This adds tests for issues brought up in bug 231393, bug 264610, bug 302575 and bug 1129564,
all of which fed into the current implementation of userTypedClear/userTypedValue. I intend
to move us away from userTypedClear, but I'm keen not to regress any of these issues, so
I'm adding automated tests to ensure that doesn't happen.
MozReview-Commit-ID: 1up2MIXzkzG
--HG--
extra : rebase_source : 4d37f13895b8c7e7aba5331664718582c6b2136c
DOM Storage is a pretty inefficient and memory-hungry storage mechanism. Session Store attempts to record DOM Storage for each tab, which leads to (possibly very large) objects being serialized once to be sent from frame/content to parent and once to be sent from the main thread to the I/O thread. This is a suspect behind a number of crashes (see bug 1106264 for a discussion on the topic).
This patch limits the amount of DOM Storage that Session Restore attempts to store. We perform a quick estimate on the amount of memory needed to serialize DOM Storage and prevent storage larger than ~10M chars being sent from frame/content to the parent. Once this patch has landed, we will need to watch FX_SESSION_RESTORE_DOM_STORAGE_SIZE_ESTIMATE_CHARS to find out whether our threshold is meaningful.
--HG--
extra : transplant_source : %26%07%ADzjT%A9%E3%B9%B9%EC%9D%97n%23%B5%F2%DAZ%CD
