This changes most of our automation builds to clang 11.0.0 rc2.
Not included:
* code coverage builds, per bug 1660341
* mingw builds, which have traditionally been on their own update cadence, and in this case are blocked anyway by bug 1658632
This will leave some unused clang-9 task definitions. I intend to clean them up, but at a later date. For now I want to focus on making sure this update sticks, since patches like this have a tendency to bounce.
Differential Revision: https://phabricator.services.mozilla.com/D88313
A few test cases fail under clang-11 on Linux debug builds only. As described in the bug, we unfortunately don't have the bandwidth to investigate, so this patch accepts the failures.
Differential Revision: https://phabricator.services.mozilla.com/D88363
For not-well-understood reasons, ld's `--gc-sections` discards a large number of the PGO bookkeeping structures that enable us to keep track of function counters, and the effect gets worse in object files generated by clang-10.
As much as I'd like to understand this better, the investigations take way too much time. As a path of least resistance, we can disable `--gc-sections` for the instrumentation phase of PGO builds. It won't harm anything since users never see those builds, and it will improve the performance of the optimized phase greatly.
Differential Revision: https://phabricator.services.mozilla.com/D78112
Some geckoview tests require gradient usage. Since background
images are async, these tests would wait for a contentful paint
to make sure the images are decoded before running the assertions.
This causes an issue because gradient-only backgrounds aren't
contentful anymore according to the latest spec.
We fix the tests by adding a transparent gif to the background
image list to trick the contentful detection.
Differential Revision: https://phabricator.services.mozilla.com/D88230
The current tests workflow works as wait for three frames, then
check if the performance entry shows up. This workflow is flaky
because the three frames piece is hardcoded and there are
chances that the paint takes longer than three frames because it
really depends on the current workload of the system.
We fix it by loading the image into memory first, so that it's
decoded before the painting.
Depends on D68647
Differential Revision: https://phabricator.services.mozilla.com/D68888
In this patch, we changed a lot of tests from PRECONDITION_FAILED to
timeout because we added the PerformancePaintTiming API so the
precodition is no longer failed. TIMEOUT is required because
these tests expect two performance paint entries, but we only
support one of them.
Depends on D68645
Differential Revision: https://phabricator.services.mozilla.com/D68646
Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
This listens to state changes set via SharedData. Those state changes are executed by
front-end code in a later patch in this series.
Depends on D87129
Differential Revision: https://phabricator.services.mozilla.com/D86719
`play` default handler is a special case, we don't want to run it arbitrarily in order to get a better user experience.
If we have an active media session, the play should only be triggered on that session, which is something a user really wants to resume. Therefore, adding some restrictions to call default play handler only when
(1) We don't have an active media session (If we have one, the play action handler should only be triggered on that session)
(2) Active media session without setting action handler for `play`
Differential Revision: https://phabricator.services.mozilla.com/D88107
As we want to have an ability to do different operations on different browsing contexts for those actions with default handlers (play/pause/stop), so in D87142 we have changed `ContentMediaController` per browsing context. Techically it's per inner window, but it means each browsing context would have one corresponding `ContentMediaController` if the web content is in that browsing context.
The approach to achieve the goal is that, when getting those actions, we would notify to the top level browsing context, then go through its children to ensure that each browsing context can be operated correctly. By doing so, we can trigger default action handler and customized action handler on different browsing context.
Eg. A page has a child iframe, which has active media session with an action handler for `pause`. A page and iframe are both playing media. When pressing `pause`, default action handler would be run on main frame, and the customized action handler would be run on iframe.
Differential Revision: https://phabricator.services.mozilla.com/D87143
Before applying this patch, `ContentMediaController` is per process, it might contains `ContentMediaControlKeyReceiver` coming from different browsing context, and we are not able to treat those receivers differently based on the browsing context they exist in.
The goal to change `ContentMediaController` per inner window is to allow us to have an ability to treat receivers in different browsing context with different operations without interering each other.
As the `ContentMediaController` control the media playback in web context, which life cycle is tight to the inner window, that is why I choose to create `ContentMediaController` on the inner window.
In addition, update the comment to make its up-to-date.
Differential Revision: https://phabricator.services.mozilla.com/D87142
We determine which media session is active media session in chrome process, but the media session in content process doesn't know the detail.
This patch would store the active session context Id on the top level WindowContext, so that media session in content process can know if it's an active context or not, which helps to trigger the action handler only on active media session, after changing our propagation mechanism in following patches.
Differential Revision: https://phabricator.services.mozilla.com/D88106
Having the fill logins context menu on PDF forms could lead to users
accidentally entering their login information into to a PDF form which
is probably not a desired or expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D88198
This stores the slot span in the object slots error for dictionary mode
objects. Since it's possible to have dictionary mode objects without dynamic
slots, this adds sentinel ObjectSlots instances for each possible dictionary
slot span up to the maximum number of fixed slots.
Differential Revision: https://phabricator.services.mozilla.com/D87888
Instead of creating an element, flushing styles and getting the computed
value back just to receive, use the existing InspectorUtils.colorToRGBA.
With some refactoring, we can completely get rid of parsing rgba strings
in LightWeightThemeConsumer too, as a benefit. This should be much
faster.
This patch tweaks the InspectorUtils API to allow taking a document, so
that system colors keep working. We could probably get away without
supporting system colors, but it'd technically be a regression, and
since we want this patch to be uplifted, and it's easy, let's avoid
breaking changes.
Differential Revision: https://phabricator.services.mozilla.com/D88200
