We have other code to make sure that options themselves are in-flow, so
we really want abspos boxes not to escape the select element.
Other browsers don't allow having out-of-flow option children at all
(they seem to force descendants to be in-flow). However that seems
fairly more complicated to implement, and I don't think it particularly
matters how we deal with this as long as we deal with it in a
sorta-reasonable way.
Differential Revision: https://phabricator.services.mozilla.com/D131785
Depends on D131439
Add a new CONTEXT_DESCRIPTOR_TYPES for top level browsing contexts, called TOP_BROWSING_CONTEXT.
The corresponding context descriptor id should be a browserId.
The FrameTransport is updated to support both CONTEXT_DESCRIPTOR_TYPES: ALL and TOP_BROWSING_CONTEXT.
A browser mochitest is added to check that broadcasts are correctly filtered for a top level browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D131440
Instead of using a broadcast boolean flag in the CommandDestination, use a contextDescriptor.
The only context descriptor type supported here is CONTEXT_DESCRIPTOR_TYPES.ALL, and the behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D131439
This was a subtle behavior change in bug 1739464. The early-return here:
https://hg.mozilla.org/mozilla-central/rev/2fb74c67b0c5#l11.40
Meant we also bailed out from user font prioritization for system fonts.
It's unclear whether that's really the best behavior but since the
intention of the regressing patch was not to change behavior, preserving
the old behavior seems better.
Differential Revision: https://phabricator.services.mozilla.com/D131899
We allow animating pseudo-elements like ::-moz-progress-bar (and we
treat them like regular elements).
Ideally we should store animations for these in the parent element as
well, so they survive reframes and such. But treating them as regular
elements right now means that we do animate them, but we never update
animations for them correctly because wrapper.rs assumed them to be
non-animatable.
Since it seems reasonable to keep allowing the animations to happen,
let's just correct the update code and add a test.
Differential Revision: https://phabricator.services.mozilla.com/D131794
Given the compat reports in bug 1484928, I don't think it's worth
keeping the current behavior.
Our behavior should match other browsers now. Rather than making
content: url() work everywhere even for otherwise-replaced elements,
just special-case this since that's what other browsers seem to do.
Differential Revision: https://phabricator.services.mozilla.com/D131797
The test logs messages in a requestAnimationFrame loop to check if logging impact
the performance of requestAnimationFrame.
The issue is that the tests logs an average of rounded values, which makes the
test results oscillate between 16 and 17 (ms), and this extra ms in enough to
trigger a perf alert as it represents a few percent of variance.
This patch makes it so we don't average, nor round the values anymore, which
shouldn't trigger perf alerts.
Differential Revision: https://phabricator.services.mozilla.com/D131795
In nsAutocompleteController::HandleKeyNavigation, we might trigger a search operation (or open the popup)
However, when we find there is already a search result received previously, and the search string is the same
as the current one, we won't trigger a new search[1] because the result should be the same.
This might be true for most of the cases, but not true when clients that perform the search is differnt.
As far as I know, there are at least 3 different autocomplete clients: form history, CC/Address autocomplete, and login manager.
For example, the same search string might return a different result when it is searched by the login manager
and by the form history component.
Here is how the intermittent occurs:
1. The page is loaded
2. Password field is detected so the login manager fetches the login data from the parent asynchronously
3. The testcase continues to run. The username field is focused
4. Autocomplete search for the focus field is triggered. Since the login manager has not yet told FormFillController
this is a field we care, we search the form history and get an empty result.
5. Login data is sent from parent to child, _fillForm is called. The LoginManagerChild calls `MarkAsLoginManagerField`
6. Key event occurs on the field. Autocomplete search is triggered again. However, the search is not executed because
[1]
7. Popup is not shown. Testcase timeout.
When #5 occurs before #3, the autocomplete search in #4 will be processed by the login manager, and we will get the result
and open the popup in this case
In the current architecture, I don't see an easy way that we can distinguish whether the autocomplete client is different
in nsAutocompleteController. So instead of doing it in nsAutocompleteController, this patch fixes this issue in FormFillController.
In FormFillController, when we call `MarkAsLoginManagerField` on a focus field, we call ResetInternalState() to
tell nsAutocompleteController to clear previous search result.
[1] https://searchfox.org/mozilla-central/rev/fb8d77331582639ea6848a61dd8ee812fac31b77/toolkit/components/autocomplete/nsAutoCompleteController.cpp#516-521
Differential Revision: https://phabricator.services.mozilla.com/D131237
This assertion is known to affect some scenarios involving inactive
scroll frames (see comment 10-11 in this bug). In Fission mode, this
is resolved by making all scroll frames active. In non-Fission mode,
we don't plan to pursue a specific fix so downgrade the assertion
to avoid annoyance for users running debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D131886
As in helper_visual_scrollbars_pagescroll.html, this test performs a
native click on a scrollbar track and needs to wait for the resulting
scroll animation to be kicked off. This fix ensures it waits long
enough.
Differential Revision: https://phabricator.services.mozilla.com/D131885