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
Some devtools tests had been forced to run in e10s with just 1
content process in bug 1301340 and bug 1303113 because they were
failing.
Now there seems to have been enough e10s messaging fixes that these
tests work again. It seems safe to re-enable multi-content-processes
for them now.
MozReview-Commit-ID: ENfDdIXvIAI
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
The action creator for removing custom devices calls the one for remove device
association directly, which skips the step of also messaging the manager.
I've made the simplest change to fix just this issue, which moves the message
sending into the action creator for this one case. Bug 1332754 will apply the
same approach to other messages (they aren't causing issues yet since they are
not called from other action creators in the same way).
MozReview-Commit-ID: AICcT2vG1wl
This gets closer to Helen's mockup. The spacing is a bit tight. When adjusting
the modal size, I used the most popular DevTools screen resolution (1366 x 768)
as a reference.
MozReview-Commit-ID: 4EjJKKhuxpA
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
If a device is active, remove it on resize. If not, leave device properties
alone, so that things like touch simulation stay enabled when resizing without
a device.
MozReview-Commit-ID: Hvo6AdTJRBJ
Use "change" instead of "update" terminology with viewport properties.
Remove redundant "viewport" word from viewport changes.
MozReview-Commit-ID: HSFLiZyTVYy
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
