This is a security product and has no good reason to instantiate a11y.
We've also seen it show up in obscure crash reports.
Differential Revision: https://phabricator.services.mozilla.com/D116536
Previously, we only deferred SendSetEmbedderAccessible calls for in-process iframes if the DocAccessibleChild hadn't sent its constructor yet.
This meant that top level content process documents (tab documents or OOP iframes) called SendSetEmbedderAccessible even if a11y insertions/removals were still being deferred.
Differential Revision: https://phabricator.services.mozilla.com/D116435
* Some helpers and a basic test for full page and visible page screenshots, using the clipboard to examine the result
* The visible page test's assertions are marked todo, as we don't actually get the expected image dimensions currently. This is possibly bug 1711101?
Differential Revision: https://phabricator.services.mozilla.com/D99854
This is its own part since it is a behaviour change. After adding recent tabs, we can add as many stale tabs as we want because the muxer will flex them with other results.
Differential Revision: https://phabricator.services.mozilla.com/D114896
I chose to do this at the level of the outer Python invocation because:
1. `python -m cProfile ...` handles writing the file and some other
details. It's possible to rebuild the functionality -- the tools
are there -- but the APIs are awkward.
2. this allows to profile `mach` internals, instead of just the
invoked command's implementation.
This uses the return code of the `get_command` subshell to transmit
the single bit of information "is the flag present".
The Python-level argument is required in order to have `--help` know
about the option and to avoid the `mach` shell script having to filter
arguments.
Differential Revision: https://phabricator.services.mozilla.com/D116151
Store CompositeTile instances in local space, and add support for compositor
transforms that can map local -> raster -> device space without access to the
spatial tree.
This is prep work for supporting picture cache tiles that are scaled by the
composite step during pinch-zoom, for low-end GPUs. Follow up patches will
port the native compositor surface and external descriptors to also work
in local space, converting to raster or device space on demand as required.
Differential Revision: https://phabricator.services.mozilla.com/D116331
The bug in question is that if a user opts into allowing one tracker on a given
site for the session, new visits to that site will allow others trackers as
well, not just the expected one.
While we're here, we also improve the web console messages to show the same
"allowing X due to opt in" message on new visits as well, not just the original
one where the user initially opted-in for that shim.
We might as well also land bug 1712959 into m-c, rather than waiting for the
next webcompat release cycle.
Differential Revision: https://phabricator.services.mozilla.com/D116642
Store CompositeTile instances in local space, and add support for compositor
transforms that can map local -> raster -> device space without access to the
spatial tree.
This is prep work for supporting picture cache tiles that are scaled by the
composite step during pinch-zoom, for low-end GPUs. Follow up patches will
port the native compositor surface and external descriptors to also work
in local space, converting to raster or device space on demand as required.
Differential Revision: https://phabricator.services.mozilla.com/D116331
To restore the stripped query parameters when ETP toggle has been set to
off, we preserve the current unstripped URI to the new loadState when
doing a reload. By doing this, it will redirect the channel back to the
unstripped URI because the loading channel is in the content blocking
allow list and it has a unstripped URI in its loadInfo.
Differential Revision: https://phabricator.services.mozilla.com/D116116
In order to respect the content blocking allow list permission, we have
to do an internal redirect to the unstripped URI. We can only do this by
using an internal redirect because the stripping was happened in loadURI
in the content process. At the moment, the content process doesn't know
the content blocking allow list principal for the cross-origin URI. So,
we don't know if we should skip the query stripping. To resolve this,
we have to redirect the chanell back to the unstripped URI in the parent
process where the permission is available.
Differential Revision: https://phabricator.services.mozilla.com/D116113
The patch makes the original redirect URI to be preserved in the
loadInfo of the redirect channel when query stripping happens during
redirects.
Differential Revision: https://phabricator.services.mozilla.com/D116112
This patch adds an attribute UnstrippedURI in the nsDocShellLoadState.
The attribute will be set if the query stripping was happening.
Otherwise, it will stay a nullptr. This attribute will be propagated to
the loadInfo, so that we can revert the query stripping in the parent
process if the loading URI is in the content blocking allow list. We can
only revert the query stripping in the parent process because we cannot
access the permission of the content blocking allow list of a
cross-origin domain. So, we can only carry the unstripped URI in the
loadInfo and perform a interal redirect to revert the query stripping.
Differential Revision: https://phabricator.services.mozilla.com/D116109
This patch adds a UnstrippedURI into the LoadInfo. This attribute
represents the channel's URI has been stripped if this attributes is not
a nullptr.
Having this attribute allows us to be able to revert the query stripping
in the case where the loading channel is in the content blocking allow
list in the parent process.
In addition, this patch removes the main thread assertion in URIUtils
given that we've made the URL construction thread-safe. This will allow
us to be able to use nsIURI directly in ParentLoadInfoForwarderArgs.
Differential Revision: https://phabricator.services.mozilla.com/D116108
This makes the following changes on autoland:
+test-linux1804-64-asan/opt-mochitest-browser-chrome-fis-e10s
And the following changes on central:
+test-linux1804-64-asan/opt-mochitest-browser-chrome-fis-e10s
Differential Revision: https://phabricator.services.mozilla.com/D116623
This makes the following changes on autoland:
+test-linux1804-64/opt-mochitest-browser-chrome-fis-e10s
+test-macosx1015-64-qr/debug-mochitest-browser-chrome-fis-e10s
+test-macosx1015-64-qr/opt-mochitest-browser-chrome-fis-e10s
+test-windows10-64-qr/debug-mochitest-browser-chrome-fis-e10s
+test-windows10-64-qr/opt-mochitest-browser-chrome-fis-e10s
And the following changes on central:
+test-macosx1015-64-qr/debug-mochitest-browser-chrome-fis-e10s
+test-macosx1015-64-shippable-qr/opt-mochitest-browser-chrome-fis-e10s
+test-windows10-64-qr/debug-mochitest-browser-chrome-fis-e10s
-test-windows10-64-shippable/opt-mochitest-browser-chrome-fis-e10s
Differential Revision: https://phabricator.services.mozilla.com/D116277
This helps execute code on navigation, even if the document loads super fast
and target actor's navigate is emitted before frontend has a chance to register the navigate event.
Differential Revision: https://phabricator.services.mozilla.com/D115825
When we adjust the playback rate on the audio track, the audio clock time would be no longer align with the graph time.
Eg. playback rate=2, when the graph time passes 10s, the audio clock time actually already goes forward 20s.
After audio track ended, the video track would start to drive the clock time but the video clock time is align with the graph time, which means it would be smaller than the audio clock in that situation.
Therefore, we have to ignore the video clock time in that case. In addition, this patch also address the duration change on video frames based on the playback rate.
Differential Revision: https://phabricator.services.mozilla.com/D115035
By using the soundtouch library, this patch implements the time stretching on the samples in AudioDecoderInputTrack when its playback rate is not 1.0f, in order to support changing playback rate on the captured media stream.
As the time stretcher has to be initialized by a fixed channel count, we would perform a realtime up-mix/down-mix for those audio chunks which have different channel count thant AudioDecoderInputTrack's initial channel count.
Differential Revision: https://phabricator.services.mozilla.com/D114560