These low level docs are getting out of date and causing confusion. Further,
they are of limited value at this stage anyway.
MozReview-Commit-ID: FSoNniNZjtj
--HG--
extra : rebase_source : fa5e02a771adcae9b0e53bd18c4eb10ebb5315ef
This test verifies that WebExt messaging works as expected for both the
background page scripts and content scripts when RDM is used.
MozReview-Commit-ID: 3fODg3nYLr7
--HG--
extra : rebase_source : ad0051f6c377f15dbe27cf6cac5c3fd07af6fac7
WebExt messaging sends several new message types to content that should be
tunneled by RDM.
This change allows them to reach content as expected in RDM mode.
MozReview-Commit-ID: GKelgOGBUKI
--HG--
extra : rebase_source : 77288fc586efbaeb9b4c344a291c7c5f815e1a15
It is possible for the frame loader swap within `gBrowser._swapBrowserDocShells`
to fail when various frame state is either not ready yet or doesn't match
between the two browsers you're trying to swap. However, such errors are
currently caught and silenced in the browser, because they are apparently
expected in certain cases. So, here we do our own check to verify that the swap
actually did in fact take place, making it much easier to track such errors when
they happen.
MozReview-Commit-ID: LwuCXJQRRVW
--HG--
extra : rebase_source : f2e523ec3a5fc14306881dd823190dfcfe7cdd7a
Add some (disabled by default) logging to the RDM swap process to speed up
future investigations.
MozReview-Commit-ID: ICuH7i5Nsq5
--HG--
extra : rebase_source : 9d20a69965572020e7a98dbfe56bbcc57df0dad1
RDM uses temporary tabs to move content around and into the tool's viewport.
This triggers events like `TabOpen` and `TabClose` for the temporary tab,
trigger unnecessary work, like alerting WebExtensions.
Avoid this noise for WebExtensions and others by absorbing these events.
Note that the _original_ browser tab is unaffected. This only changes temporary
tabs RDM uses during the swapping process.
MozReview-Commit-ID: H8kBYBma6i9
--HG--
extra : rebase_source : 37150c7cb889ff64982f33f991a64fe50eacfd04
Sometime during Firefox 56, the `dataTransfer` property was removed, so this
started to fail. It was a bit strange anyway, since we have a principal on the
outer browser.
Adds a test to cover this use case.
MozReview-Commit-ID: 9UOCc77ZRxk
--HG--
extra : rebase_source : f743c7704ff8fc0e52b7facb11e0e9b6aca9670e
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
--HG--
extra : rebase_source : dff8a35b25994b49f2e31888d49ffcb6b55402bb
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
--HG--
extra : rebase_source : 51c3beeaa4ff081d1f9d3ddd5e00b83c56aa15e1
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
--HG--
extra : rebase_source : 5cc2deafc31f8f58d13d78e5b2524d60897bf5b9
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
--HG--
extra : rebase_source : 6c945bc74c5b4a366c461f34566db1dfc2eb0435
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
