Since JSWindowActors don't have direct access to synchronous messaging,
ChromeScript callers are going to need to migrate to asynchronous messaging
and queries instead.
Since there's no comparable API to sendQuery for frame message managers, this
patch adds a stub that uses synchronous messaging, but makes the API appear
asynchronous, and migrates callers to use it instead of direct synchronous
messaging. This will be replaced with a true synchronous API in the actor
migration.
Fortunately, most of the time, this actually leads to simpler code. The
`sendQuery` API doesn't have the odd return value semantics of
`sendSyncMessage`, and can usually just be used as a drop-in replacement. Many
of the `sendSyncMessage` callers don't actually use the result, and can just
be changed to `sendAsyncMessage`. And many of the existing async messaging
users can be changed to just use `sendQuery` rather than sending messages and
adding response listeners.
However, the APZ code is an exception. It relies on intricate properties of
the event loop, and doesn't have an easy way to slot in promise handlers, so I
migrated it to using sync messaging via process message managers instead.
Differential Revision: https://phabricator.services.mozilla.com/D35055
--HG--
extra : rebase_source : d5707e87f293a831a5cf2e0b0a7e977090267f78
extra : source : 75ebd6fce136ab3bd0e591c2b8b2d06d3b5bf923
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 941298157e7c82f420cf50ce057154ce9b85301c
extra : source : 189dc8a359815e059a4a217f788d183260bb2bfe
Add [LegacyWindowAlias] extended attribute support for WebKitCSSMatrix and webkitURL.
Differential Revision: https://phabricator.services.mozilla.com/D35601
--HG--
extra : moz-landing-system : lando
We probably just can remove it given that no other implementations are there.
Differential Revision: https://phabricator.services.mozilla.com/D36491
--HG--
extra : moz-landing-system : lando
This patch is based on Makoto Kato-san's patch.
This patch implements `mozilla::dom::StaticRange` class and creating some
static factory methods.
Then, makes `AbstractRange` has a utility method of `SetStartAndEnd()`
method of `nsRange` and `StaticRange` for sharing same logic in one place.
However, there are some additional work is required only in `nsRange`, e.g.,
`nsRange` needs to start observing mutation of the range, but `StaticRange`
does not it. Therefore, it's implemented as a template method which takes
`nsRange*` or `StaticRange*` as a parameter. Then, each `DoSetRange()`
method of them can do different things without virtual calls.
Note that `StaticRange` does not have any properties, methods nor constructor.
Therefore, we need additional API to test it.
Differential Revision: https://phabricator.services.mozilla.com/D35143
--HG--
extra : moz-landing-system : lando
This patch is based on the patch created by Makoto Kato-san.
`Range` and `StaticRange` have common base interface, `AbstractRange`.
https://dom.spec.whatwg.org/#abstractrange
This interface has simply returns `startContainer`, `endContainer`,
`startOffset`, `endOffset` and `collapsed`.
Different from the original patch's approach, this patch moves related
members in `nsRange` to `AbstractRange` since this approach avoids
virtual call cost. Additionally, this patch makes them not throw as
declared by the spec. As far as I know, the destruction cost of
`ErrorResult` may appear in profile so that we should avoid creating
the instance if we can avoid it.
Unfortunately, the instance size of `nsRange` becomes larger with this
patch. The size is changed from 176 to 184. I.e., now, `nsRange`
requires bigger chunk.
Differential Revision: https://phabricator.services.mozilla.com/D35140
--HG--
extra : moz-landing-system : lando
Two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
Differential Revision: https://phabricator.services.mozilla.com/D35870
--HG--
rename : dom/xul/test/test_bug486990.xul => dom/xul/test/test_bug486990.xhtml
rename : layout/base/tests/file_bug465448.html => layout/base/tests/chrome/file_bug465448.html
rename : layout/base/tests/test_bug465448.xul => layout/base/tests/chrome/test_bug465448.xul
extra : moz-landing-system : lando
Two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
Differential Revision: https://phabricator.services.mozilla.com/D34782
--HG--
rename : layout/base/tests/test_bug465448.xul => layout/base/tests/chrome/test_bug465448.xul
extra : moz-landing-system : lando
The ServiceWorker is terminated by idleWorkerTimer timeout, and in slow platforms/machines, it would cancel the uncompleted fetching and make unexpected behavior during running tests.
The SW idle termination implementation has no defects, so the fix would just double the dom.serviceWorkers.idle_timeout to let fetchings have more chance to finish before idleWorkerTimer timeout.
Differential Revision: https://phabricator.services.mozilla.com/D35555
--HG--
extra : moz-landing-system : lando
This change comes in two parts. First, the code in WindowGlobalChild was changed
to detect the in-process case, and instruct the nsFrameLoader to become a
non-remote nsFrameLoader, and second the logic in WindowGlobalParent was updated
to ensure that the OwnerProcessID is updated after the change.
Differential Revision: https://phabricator.services.mozilla.com/D35060
--HG--
extra : moz-landing-system : lando
Currently Firefox creates a 2D DOMMatrix when certain values of 16 elements are zero, so this change fixes it to align with the spec.
Differential Revision: https://phabricator.services.mozilla.com/D35326
--HG--
extra : moz-landing-system : lando
This patch adds the ability to load cross domain iframes in the
background to make the top level documents finish earlier.
This is an experiment feature that we'll keep it disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D24938
--HG--
extra : moz-landing-system : lando
Per https://bugzilla.mozilla.org/show_bug.cgi?id=1550625#c5 there is no
mechanism available for FIDO U2F JS API operations on Android. The exposed API
is FIDO2/WebAuthn-only. As such, Firefox cannot support FIDO U2F JS API
operations on Android, and we should disable the u2f preference so that
window.u2f is not set inappropriately.
Updated to fix test_interfaces.js
Differential Revision: https://phabricator.services.mozilla.com/D31695
--HG--
extra : moz-landing-system : lando
Amend several test files for triggering eval() assertion through simpletest.js
Differential Revision: https://phabricator.services.mozilla.com/D30474
--HG--
extra : moz-landing-system : lando
We can run /debug mochitests against geckoview for the cost of another dozen
or so test annotations. Both /opt and /debug mochitests are nearly worthy of
tier 1, but still waiting for bug 1534732.
Differential Revision: https://phabricator.services.mozilla.com/D30931
--HG--
extra : moz-landing-system : lando
