This patch enables multi-value calls and returns, adding some tests, and
conditionally disabling a couple expect-fail reftests that now pass.
It also changes to make calling multi-result WebAssembly functions from
JavaScript raise a run-time error, and likewise for calling out to
multi-result JS function from wasm. Previously these would abort at
stub generation time.
Differential Revision: https://phabricator.services.mozilla.com/D65502
--HG--
extra : moz-landing-system : lando
Handle rfc822Name and iPAddress subjectAltNames, and replace "[object
Object]" with an explicit "unsupported" string for otherName.
Differential Revision: https://phabricator.services.mozilla.com/D65749
--HG--
extra : moz-landing-system : lando
This patch adds an asynchronous hit tester that can perform hit testing queries without blocking on a synchronous message to the render backend thread, which is often busy building frames. This is done by having a shared immutable hit tester readable by any thread, atomically swapped each time the render backend processes a new scene or frame.
In order to asynchronously hit test without causing race conditions with APZ intenral state, the hit tester has to be built while the APZ lock is held.
Differential Revision: https://phabricator.services.mozilla.com/D45345
--HG--
extra : moz-landing-system : lando
This patch removes a `storage.local.clear()` call from raptor-webext for causing a high number of intermittent failures. It also adds a default value for `--host` in the mozharness raptor. Finally, a delayed startup for raptorRunner is added with the hope that this will further decrease intermittents (right now, it might be starting at a very noisy time).
Differential Revision: https://phabricator.services.mozilla.com/D65893
--HG--
extra : moz-landing-system : lando
This removes the obsolete backend. Notes on some of the less obvious changes
made as part of this patch:
- some of the gFoo style getters in Blocklist.jsm were only used by the XML
version of the blocklist; I've removed them and tried to remove spurious
settings of those properties in the remaining tests.
- some utility methods (e.g. distribution information getters) were also only
used for the XML version (for the update URL).
- it's no longer necessary to test switching implementations.
- in browser/base/content/test/plugins/, we ran some tests from two manifests
in order to run them with both blocklist backends. The simplest way of
reducing this back down to one was to remove the remote-settings one. If I'd
been more future-oriented when I created the duplication, perhaps I would
have moved the XML version out into a different manifest instead, but I
didn't, so now it looks like we're removing the modern one, whereas really
we're going to be running the modern one as part of the "normal" tests and
we're no longer running the "old" tests.
- removed all mentions I could see of extensions.blocklist.url which is no
longer used for anything.
- per https://bugzilla.mozilla.org/show_bug.cgi?id=1016555#c23, updated
references for the OneCRL timing and how it relates to blocklist updates.
Differential Revision: https://phabricator.services.mozilla.com/D64933
--HG--
extra : moz-landing-system : lando
The reason of intermittent failure of `test_bug656379-2.html` is, synthesized
`mousemove` event coming from the parent process causes `mouseout` and
`mouseleave` events of the last synthesized `mousemove` in the test. The
reason is, synthesized `mousemove` for tests makes `PresShell` in the content
process record the cursor location, but won't make it `PresShell` in the
parent process do it. Therefore, parent process may synthesize `mousemove`
event for the system cursor position which does not match with the synthesized
mouse location in the content process. Therefore, `:hover` state may be
updated unexpectedly.
This patch makes `WidgetEvent::mFlags` have a flag to indicate whether it
came from another process. Then, makes `PresShell::HandleEvent()` ignore
synthesized `mousemove` events coming from another process only when the
recorded mouse location was set by a mouse event synthesized for tests.
Differential Revision: https://phabricator.services.mozilla.com/D65282
--HG--
extra : moz-landing-system : lando
It's valid thing that a container of a `Range` of `Selection` is not a content
node. Actually, it can be a `Document` node. But it's illegal case for
editor. So, if `HTMLEditor` meets such case, it does not need to do anything.
This patch makes that if `HTMLEditor` meets the situation at very first time
of public edit action method, it returns "OK" for avoiding new exception case.
Otherwise, i.e., it's an XPCOM API or meeting such situation after a DOM
mutation, returns error.
Differential Revision: https://phabricator.services.mozilla.com/D65278
--HG--
extra : moz-landing-system : lando
This adds an `implementation-status` field to the wpt metadata with 3
possible values; "not-implementing", "backlog" and "implmenting" (the
latter being the same as the default value). It also adds a
`--skip-implementation-status` command line argument to wptrunner that
can be used to skip running tests with the specified implementation
statuses. This is primarilly to allow gecko to avoid running tests (or
run tests less frequently) for things where we don't implement the
spec and don't plan to either ever or in the current roadmap.
Differential Revision: https://phabricator.services.mozilla.com/D65765
--HG--
extra : moz-landing-system : lando
layout/reftests/bugs/370422-1.html changes the size of a fission iframe.
Bug 1615504 made sure the visible rect got to the child process. But there is still a failure mode where (I assume) all invalidations/painting of changing the document size in the iframe content process happens before the effects visible rect ipc msg arrives at the content process.
In this case we still need to invalidate even though we use the correct visible rect on the builder we need a dirty rect that includes the unveiled area.
Depends on D65888
Differential Revision: https://phabricator.services.mozilla.com/D65889
--HG--
extra : moz-landing-system : lando
Bug 1603714 showed there were `UntrustedModulesData` instances in which a load
event pointed to a module which did not exist in the modules list.
This patch adds `MOZ_DIAGNOSTIC_ASSERT` to the following places to narrow down
when it happened.
Given that the number of the impected users seems big (~200 crashes/day on Nightly),
we activate the assers with a probability of 1/16 (~12.5 crashes/day).
1. When processing load events
1-1. [Content] `UntrustedModulesProcessor::CompleteProcessing:`
Verify events of a trusted module were eliminated by `GetModulesTrust`
1-2. [Content] `UntrustedModulesData::AddNewLoads`:
Verify a new `ModuleRecord` matches the event
1-3. [Content] `UntrustedModulesProcessor::CompleteProcessing`:
Verify processed data after new items were appended.
2. When processed data is sent
2-1. [Content] `UntrustedModulesProcessor::GetAllProcessedData`:
Verify processed data before serialization.
2-2. [Content] `ParamTraits<mozilla::UntrustedModulesData>::WriteEvent`:
Verify processed data before transferring to the browser process
2-3. [Browser] `ParamTraits<mozilla::UntrustedModulesData>::ReadEvent`:
A final point to catch this integrity problem. We had an IPC error here.
Differential Revision: https://phabricator.services.mozilla.com/D59964
--HG--
extra : moz-landing-system : lando
The blocklist variable `BROWSER_PROCESS` did not work as expected. Entries
defined there were blocked not only in the browser process but also in the
child process.
This patch makes sure entries in `BROWSER_PROCESS` are blocked only in the
browser process.
Differential Revision: https://phabricator.services.mozilla.com/D65248
--HG--
extra : moz-landing-system : lando
If an addon is updated and moves permissions between required to optional, we
want to retain the previously granted permission so the extension does not have to
request the permission from the user again. We also handle permission removal
and changes to preferences based on permissions.
Differential Revision: https://phabricator.services.mozilla.com/D64696
--HG--
extra : moz-landing-system : lando