This adds a single new method, which acts like sendAsyncMessage, but
also returns a promise. This promise is fulfilled when the promise
returned from the receiveMessage callback is resolved.
```
partial interface JSWindowActor {
[Throws]
Promise<any> sendQuery(DOMString messageName,
optional any obj,
optional any transfers);
}
```
Differential Revision: https://phabricator.services.mozilla.com/D27809
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::inputSource to WidgetMouseEventBase::mInputSource
Differential Revision: https://phabricator.services.mozilla.com/D25322
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::pressure to WidgetMouseEventBase::mPressure
Differential Revision: https://phabricator.services.mozilla.com/D25314
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::button to WidgetMouseEventBase::mButton.
Differential Revision: https://phabricator.services.mozilla.com/D25309
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::buttons to WidgetMouseEventBase::mButtons
Differential Revision: https://phabricator.services.mozilla.com/D25297
--HG--
extra : moz-landing-system : lando
This patch adds an ID to ensure that we avoid canceling content JS if the next
page already started loading by the time we're ready to try canceling the JS.
Differential Revision: https://phabricator.services.mozilla.com/D25164
--HG--
extra : moz-landing-system : lando
In this part, we pass along the navigation type (and index for when using the
dropdown on the back/forward buttons). This allows us to check if there's a
top-level load "between" the start and end pages.
The patch might look a bit strange, since we're passing the navigation
operation to two places from RemoteWebNavigation.js (the normal message passing
that existed before this patch and the HangMonitor channel in this patch). This
is primarily to make it easier to stop passing the navigation info along the
HangMonitor channel once session history is uplifted into the parent process.
At that point, the check for whether there's a top-level load could happen in
TabParent (I think).
Differential Revision: https://phabricator.services.mozilla.com/D23090
--HG--
extra : moz-landing-system : lando
This patch passes a message through the HangMonitor channel when navigating
through history to cancel content JS that could hang the chrome JS in the
content process responsible for history navigation. If the content JS is
actually canceled, this also disables the BF cache for the current page, since
it could end up in an inconsistent state due to the JS cancellation.
Differential Revision: https://phabricator.services.mozilla.com/D23089
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
Don't assume XPCOM_MEM_BLOAT_LOG is a filename. XPCOM_MEM_BLOAT_LOG and XPCOM_MEM_LEAK_LOG can be set to a filename or "1" or "2" for logging to stdout and stderr respectively.
Set the debug write directory for XPCOM_MEM_LEAK_LOG in the same way we already to for XPCOM_MEM_BLOAT_LOG.
Differential Revision: https://phabricator.services.mozilla.com/D27968
--HG--
extra : moz-landing-system : lando
This line appears to be perma-failing right now in `Android 7.0 x86-64
opt : M[tier-2](2)`. This seems to be being caused by the PContent's
channel being closed during shutdown also causing TabParents to be shut
down too late, after the document which they're embedded in has started
dying(?)
This patch just does the "obvious" thing of adding a null check (due to
it looking like a null dereference).
Differential Revision: https://phabricator.services.mozilla.com/D27947
--HG--
extra : moz-landing-system : lando
When a remote type mismatch is found for a subframe, this patch checks if
fission is enabled for that window. If it is, it triggers a process switch,
continuing the load in a new process.
With this patch, subframes will only change process when navigating to a HTML
subframe, and not when navigating to a non-HTML subframe. That will be fixed in
a follow-up. This patch also does not change the remote type selection logic,
so only very limited types of remote iframes are supported.
Differential Revision: https://phabricator.services.mozilla.com/D27513
--HG--
extra : moz-landing-system : lando
This adds a codepath to the process switching logic to, rather than triggering
a fresh load, resume a process switching load.
Differential Revision: https://phabricator.services.mozilla.com/D27512
--HG--
extra : moz-landing-system : lando
This code builds on top of the E10S "remote tabs" configuration system to add a
system for specifying that remote subframes should be used. Fission can be
enabled for a window by including the "fission" flag in options when opening
the window.
Differential Revision: https://phabricator.services.mozilla.com/D26560
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
This should not have any major behaviour changes, with the following exceptions:
1. The method for receiving messages from IPC is called `receiveMessage` rather
than `recvAsyncMessage`. This is more consistent with existing code, so
should be OK.
2. Exceptions will be correctly reported when thrown within a callback.
Differential Revision: https://phabricator.services.mozilla.com/D26547
--HG--
extra : moz-landing-system : lando
This avoids a racy situation early during WGP creation where a null documentURI
can be read incorrectly.
Differential Revision: https://phabricator.services.mozilla.com/D26555
--HG--
extra : moz-landing-system : lando
Some methods take `const nsCOMPtr<nsIPresShell>&` as their argument to make
their callers guarantee the lifetime. However, currently all of them are
marked as `MOZ_CAN_RUN_SCRIPT`. So, it's safe to change them to raw pointer.
Additionally, this patch makes them take `mozilla::PresShell*` directly
rather than via `nsIPresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D26456
--HG--
extra : moz-landing-system : lando
This patch makes `TabChild` use `mozilla::PresShell` directly.
Then, renames `TabChild::GetPresShell()` and `TabChild::GetDocument()` to
`TabChild::GetTopLevelPresShell()` and `TabChild::GetTopLevelDocument()` to
make what they do clearer (e.g., see the change in `PresShell.cpp`).
Differential Revision: https://phabricator.services.mozilla.com/D26455
--HG--
extra : moz-landing-system : lando
This patch makes `nsDocShell::GetPresShell()` and
`nsDocShell::GetEldestPresShell()` return `mozilla::PresShell*` and
some non-public methods use `mozilla::PresShell*` directly.
Differential Revision: https://phabricator.services.mozilla.com/D26424
--HG--
extra : moz-landing-system : lando
