Although HyperTextAccessibleBase implements these, we leave the HyperTextAccessible implementations (overriding the base) because they do caching.
Depending on performance, we may eventually want to move the caching into the base implementation.
I decided not to do this initially because it will use extra memory in the parent process and it may be a premature optimisation.
Differential Revision: https://phabricator.services.mozilla.com/D127207
This will contain methods that can be used for both local and remote Accessibles.
It is inherited into both HyperTextAccessible (local) and RemoteAccessibleBase.
Differential Revision: https://phabricator.services.mozilla.com/D127206
Add newtab pref checks and record events for when checkbox button is handled. Split up trigger tests to own file and share telemetry helpers from head.js.
Differential Revision: https://phabricator.services.mozilla.com/D127722
With this change, we no longer have mutable state stored inside
the `ReferenceFrameInfo` struct, which will be important as we
introduce the follow up patches to retain the spatial tree
between display lists.
Differential Revision: https://phabricator.services.mozilla.com/D127726
This patch:
- moves the AutoNestedEventLoopAnnotation into SpinEventLoopUntil.h
- introduces the motivated SpinEventLoopUntil
- maps remaining SpinEventLoopUntil instances to SpinEventLoopUntil with "Missing motivation."
- changes relevant uses in nsThread and nsThreadManager to the motivated SpinEventLoopUntil
- changes all uses with IgnoreAndContinue behavior to the motivated SpinEventLoopUntil
Differential Revision: https://phabricator.services.mozilla.com/D126714
This allows certain routers to signal us to disable DoH when they are not capable of
responding with NXDOMAIN or no A records.
Differential Revision: https://phabricator.services.mozilla.com/D127538
This patch begins re-implements ReadableStreams using WebIDL and DOM technology (vs the existing JS streams implementation). Some more background is [here](https://docs.google.com/document/d/1MWRkF32KV60ngOY-Ip4PnKbCMvl6VK_Y9QLED8MJJxg/edit#)
This is guarded under a configure flag `--enable-dom-streams`
1. ByteStreams and ReadableStream.tee will come in future patches.
2. I intentionally crash in other parts of the DOM that require streams (Fetch, Response, Blob), until the integration work is done in future patches.
My current plan for that integration doesn't involve re-creating the alternative 'external streams' API from SpiderMonkey's implementation, but I have yet to do enough development to verify that will work.
Differential Revision: https://phabricator.services.mozilla.com/D122643
- Adding a test to validate behavior on non-tracking first-party requests
- Correct the result of a tracking same-origin request (now hasStorageAccess() == false when cookiePolicy = 2)
- Add check near the top of Document::HasStorageAccess to immediately return false when cookiePolicy is REJECT.
Differential Revision: https://phabricator.services.mozilla.com/D126399
NOTE: this issue in the test_ext_new_tab_processType.html test was not actually the one triggering
the intermittent failures being tracked by this bug, but while investigating the issue I did notice
an unexpected tab in the screenshots attached to the failures and looked into fix it to confirm
if it was related or not to the failures triggered while running test_ext_webrequest_basic.html.
Differential Revision: https://phabricator.services.mozilla.com/D127484
The underlying reasons for the test to fail for a timeout seems to be the same
ones that D94613 was meant to fix:
- a favicon request may be triggered at a random time while one of the test case
in the test file is asserting the intercepted web requests
- a previous run (in particular when running under --verify or as part of a TV job)
may have cached the stylesheet and the resulting webrequest may not match
the properties expected (and asserted) by the test case
The original patch was attached and pushed to autoland from Bug 1633189
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1633189#c46), but it seems that
it has been backed out (https://bugzilla.mozilla.org/show_bug.cgi?id=1633189#c47)
and instead we ended up landing a patch (D123339) that skipped the test in
linux-asan-opt.
NOTE:
- The unexpected favicon request which was making the test case to permafail
on the build infrastructure is only triggered when "browser.chrome.guess_favicon"
is set to true, which is actually explicitly set in mochitest-common.ini, but
apparently those preferences are not being set when the test is executed locally
through `mach mochitest` / `mach test`
- To be able to reproduce the same behavior when running the test locally,
the pref has to be set through the --setpref command line option:
mach mochitest --setpref "browser.chrome.guess_favicon=true" ...
Differential Revision: https://phabricator.services.mozilla.com/D127398