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.
In bug 1313933, we removed the session store black magic that RDM used to do in
order to hide the container tab.
Unfortunately, that fix appears to have been imperfect. Session store has a
fallback path that can still record the current URL, causing the container URL
to be recorded anyway, even though we asked nicely to please not do that.
In this change, we try a fresh approach of wedging the session history listener
for the container tab so it can't record anything. This avoids the racy
approach that was used before bug 1313933 while still appearing to block the
container URL from being recorded.
MozReview-Commit-ID: JZTYzMAvaEM
By using `LOAD_FLAGS_BYPASS_HISTORY`, we can tell session history explicitly to
ignore the entry for the container UI (which is meant to remain hidden from the
user).
This allows us to remove the horrible racy hack that attempted to have the same
effect.
MozReview-Commit-ID: LnhJpO9UbNI
When starting and stopping RDM, we need want to ensure tab listener state flags
are preserved for the tab involved, which is a bit tricky with the tab dance
RDM is doing.
The state flags ensure the browser will call the correct handlers when switching
tabs to update the primary browser UI. For example, this is needed to correctly
update the enabled state of the view source command for the current tab.
MozReview-Commit-ID: 7lKY0DKxgJH
In bug 1318767, `updateBrowserRemoteness` was changed to take the `remoteType`
as part of an options argument, but the RDM call site wasn't updated.
MozReview-Commit-ID: 8GSSwicaHvz
In bug 1310771, the session store process for gathering data from content was
changed so that the key "historychange" is used instead of "history". Kept the
check for "history" as well, since other places in session store still test for
it.
MozReview-Commit-ID: 4xF7FkxkriI
Minimal support for <a target/> and window.open() which just ensures we at
least open them somewhere (in a new tab). The following things are ignored:
* Specific target names (everything treated as _blank)
* Window features
* window.opener
These things are deferred for now, since content which does depend on them seems
outside the main focus of RDM.
MozReview-Commit-ID: AKEQkKbJicJ
Assist tabbrowser.xml with processing some events such as MozLayerTreeReady
which bubble up from the remote content frame by adding the inner browser to the
WeakMap from browser to tab.
Most likely this should have been in place all along, but a change from bug
1279086 made it more apparent that it was missing because an error is now thrown
when no tab is found for a browser.
MozReview-Commit-ID: 9wYAOcySkN
Bug 1279086 removed setDocShellIsActiveAndForeground and added preserveLayers in
its place. This updates the RDM tunnel to match.
MozReview-Commit-ID: DarZxxTkHVS
It is now possible keep the toolbox open while toggling RDM open and closed.
The toolbox will follow the frame as it moves and update the message manager it
uses internally with each move.
MozReview-Commit-ID: DvLzCmOXfnb
