wpt no longer supports this, so the test resolver doesn't work.
Since mozbuild always used Py 3 this doesn't seem to be a problem
Differential Revision: https://phabricator.services.mozilla.com/D106765
Upstream wptserve just switched to Python 3 only. That's fine for
web-platform-tests, but it turns out that some marionette harness
tests are also using wptserve and are still on Python 2.
Since fixing marionette harness turns out to be non-trivial and this
blocks other wpt work, this patch does the following:
* Temporarily vendors the last wptserve revision that works with
Python 2 in to testing/web-platform/mozilla/tests/tools/wptserve_py2
* Configures the mach virtualenv to use that copy for Python 2 modules
only.
* Configures the test packaging system to also put that copy in the
common tests zip. Requirements files are updated to use either the
Python 2 version or the Pyhton 3 version as required.
Differential Revision: https://phabricator.services.mozilla.com/D106764
The current Python 3 code assumes that sys.stdout is always the actual
stdout. But if some other code already wrapped it with a file-like API
but no buffer attribute then we end up failing.
Differential Revision: https://phabricator.services.mozilla.com/D106761
As it won't after that if something flushes (because
FlushPendingNotifications will just ignore the flush if the sink is no
longer a document observer).
Otherwise we might not notify of some document insertions, and that
might reasonably confuse layout if it has started before.
The reason we don't have more similar crashes seems to be two different
things:
* That in the crashtest, the custom element triggers a partial parser
flush via the innerHTML setter while the parser is creating the
element. That causes the parser to flush the previous text node
(which tells layout to go look under the <body> for children) but
unless we FlushTags() once we're done we won't know about the
custom-element child.
* That there's no end tag for the <body> or <html> nodes, so we don't
reach this code when we end them:
https://searchfox.org/mozilla-central/rev/df23c6e58c6be1eb8399e475878f73d4867bef87/dom/xml/nsXMLContentSink.cpp#1041-1047
Differential Revision: https://phabricator.services.mozilla.com/D106421
This changes Zone::debugScriptMap to be a WeakMap rather than having its entries marked from BaseScript::traceChildren.
This simplifies script marking and removes some code from Zone.cpp. Unfortunately it does also adds a couple of complications:
1) We need to wrap DebugScript in a JSObject so we can use it as a WeakMap value. That leads to:
2) We need to do a bunch of extra rooting whenever we might create a DebugScript.
I tried making WeakMaps allow non-GC thing values but that also got complicated as marking relies on comparing the mark state of the key to that of the value (and the map) and this would require tracing the value and then combining the mark state of child pointers.
Differential Revision: https://phabricator.services.mozilla.com/D105789
Starting with JumpTable, document how tiering and jit-entry stubs work
globally.
Clean up a little bit of naming: the "provisional jit-entry stub" is
really the "provisional lazy jit-entry stub", so make that clear.
Differential Revision: https://phabricator.services.mozilla.com/D104078
This uses `pointer-events: none` on `:disabled` to prevent unexpected hover/hover:active states, and removes `:enabled` completely to make the selectors work on <a> tags.
Differential Revision: https://phabricator.services.mozilla.com/D106886
This patch:
-Maintains consistency between the fxa and remote tabs' panels "sync now" buttons
-Removes a fluent string no longer in use
-Restores tooltip functionality
Differential Revision: https://phabricator.services.mozilla.com/D106651
This is in preparation for the next patch the virtualizes ChildAtPoint
in the Accessible class. LocalChildAtPoint allows us to house local-only
child at point implementations.
Differential Revision: https://phabricator.services.mozilla.com/D106679
Since merging stencils is a read-only operation for the source delazification
stencil and we already have a borrowed stencil at caller, it is more
consistent with our conventions to pass a CompilationStencil& instead of an
ExtensibleCompilationStencil&.
Differential Revision: https://phabricator.services.mozilla.com/D107014
