This patch doesn't impact behavior.
The pref "gfx.font_loader.interval" used to control certain aspects of
font-loading behavior, but that code has evolved and we no longer read the
value of this pref anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D155183
This matches what Linux and macOS do, and that allows the fix for bug 1782623
to work on Windows for unstyled selects.
This also simplifies the CSS (though it adds a new system color which is a bit
more annoying). I filed https://github.com/w3c/csswg-drafts/issues/7561 to
propose adding a more generic way to do this in the future (not just for
Firefox).
Differential Revision: https://phabricator.services.mozilla.com/D153549
This makes us use light or dark select popups on supported platforms
based on the background of the select element, which allows us to use
the right scrollbar color.
Depends on D153424
Differential Revision: https://phabricator.services.mozilla.com/D153425
Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
We're already batching similar styles, so by using classes instead of
style attributes and :nth-child selectors we allow the elements to share
styles, and make their styling more efficient over-all.
Differential Revision: https://phabricator.services.mozilla.com/D132829
Share the concept of a panel content with all other menupopups / panels.
This avoids importing global.css in the shadow tree, and renames the
arrowcontent part to just "content", since we want to introduce a
"content" part for other panels.
This shouldn't change behavior but makes bug 1708136 a matter of
tweaking a couple CSS rules and fixing up test failures.
Differential Revision: https://phabricator.services.mozilla.com/D113990
Share the concept of a panel content with all other menupopups / panels.
This avoids importing global.css in the shadow tree, and renames the
arrowcontent part to just "content", since we want to introduce a
"content" part for other panels.
This shouldn't change behavior but makes bug 1708136 a matter of
tweaking a couple CSS rules and fixing up test failures.
Differential Revision: https://phabricator.services.mozilla.com/D113990
Broadly, this patch does 2 things:
- it mirrors the logic bug 1702258 introduced for <select> styling for <option> styling
- it enforces that if the website specifies custom foreground colours for options,
we use the website-specified colour for the option background, too (even if it
matches the UA/select style).
I also added automated testing for 3 cases:
1. the default dark mode situation (where we expect dark mode styles),
2. the case from the bug where the website specifies `#fff` for the background
of the select and the background of the options, but specifies a custom
foreground colour for the option (but not the select).
3. a very similar case where the website only specifies the background on the
select, and only the foreground on the option.
Differential Revision: https://phabricator.services.mozilla.com/D114382
Change the height of a window opened during the test now that menus on windows 10 are larger. Make sure that the zoom level is reset after the test so that running the test again doesn't use the old zoom level. The default value of 'ignorekeys' is 'shortcuts' on Windows so reset this properly otherwise the test fails if run again.
Differential Revision: https://phabricator.services.mozilla.com/D112407
Account for the border and padding now on the inner arrowscrollbox, and increase some window and margin
sizes to account for the menu being larger in Windows 10.
Differential Revision: https://phabricator.services.mozilla.com/D110587
If the site specifies the background-color, we also specify the color to the
HTML UA style. This fixes the msn issue in a better way.
Unstyled selects would still get dark mode.
Differential Revision: https://phabricator.services.mozilla.com/D110586
Currently the default value of buttons is set to
MOUSE_BUTTONS_NOT_SPECIFIED, which defers calculation of the value to
the DOMWindowUtils GetButtonsFlagForButton function. This calculates a
default value based upon the value of the button key.
By specifying a default button value of 0, which has a meaning of
ePrimary, the buttons value is calculated as the
ePrimaryFlag (1), suggesting that a button was pressed.
This patch changes the behaviour to set the value of buttons based on
the original value of button before the default was applied. The value
of buttons also considers the event type to ensure that a mousedown
event has a default value calculated by DOMWindowUtils.
With the new behaviour:
- if a value was explicitly set for buttons, this is used
- if a value was explicitly set for button, then the not-specified
constant is used to defer calculation to DOMWindowUtils
- if an event type was specified and that event type was not the
'mousedown' event, then the no-button constant is used
- if an event type was not specified or it was for the 'mousedown'
event, then the not-specified constant is used to defer calculation to
DOMWindowUtils
Differential Revision: https://phabricator.services.mozilla.com/D101690
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
(Instead of applying it directly to the menulist).
Since it's not inherited, we need to get the right value over to the scrollbox.
For that, export it from the arrowscrollbox, with the same name as the places
menupopup uses for the same purpose.
Differential Revision: https://phabricator.services.mozilla.com/D95887
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
So that they use the select background color by default. The code in
SelectParent expects this when figuring out whether to set background colors
too. This matches other browsers and MacOS, see:
data:text/html,<select style="background: red"><optgroup label="foo"><option>Bar</option><option>Baz</option></optgroup></select>
Differential Revision: https://phabricator.services.mozilla.com/D95690
