This should do nothing until bug 1744009 lands. It would also need
bug 1596852 to be usable, but no reason to not land it now.
Differential Revision: https://phabricator.services.mozilla.com/D132732
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
this.browser in toolkit/actors/ControllersParent.jsm is the top level browser, ie the browser holding the root content document. So the conversion that happens in that file converts the coordinates to be relative to the root content document, but they need to be relative to the root of whichever child process we are sending the event to.
The best way I found out how to do this was to pass the coords down to the child process still relative to the parent process widget and then in the child process use the child to parent transform matrix to make them relative to the root widget in the child process.
I needed a new nsIDOMWindowUtils functions because I don't think there is anything existing to do this.
Differential Revision: https://phabricator.services.mozilla.com/D126861
CheckCurrentWord on content process causes sync IPC, so I would like to remove
this call on content process. New nsIEditorSpellChecker.suggest method can
avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D119937
Options can change styles for a variety of reasons and we don't want
transitions on them to re-update the whole menulist.
Differential Revision: https://phabricator.services.mozilla.com/D121353
This avoids starting autoscroll on SVG links, and on HTML links that
contain SVG, by sharing the code that browser's ClickHandlerChild uses
to detect links into BrowserUtils, and using that from AutoScrollChild
to determine if the click happened on top of a link. It also adds a
test so we avoid regressing this in future.
When running the test, I noticed an error from ClickHandlerParent
when the browser for which we receive a click has gone away, and
fixed it by adding a nullcheck and early return.
Differential Revision: https://phabricator.services.mozilla.com/D120024
This avoids starting autoscroll on SVG links, and on HTML links that
contain SVG, by sharing the code that browser's ClickHandlerChild uses
to detect links into BrowserUtils, and using that from AutoScrollChild
to determine if the click happened on top of a link. It also adds a
test so we avoid regressing this in future.
When running the test, I noticed an error from ClickHandlerParent
when the browser for which we receive a click has gone away, and
fixed it by adding a nullcheck and early return.
Differential Revision: https://phabricator.services.mozilla.com/D120024
Now, `nsIFrame::HandleEvent` moves selection at middle mouse button down. This
occurs before dispatching the event into the system event group. Therefore,
`AutoScrollChild` cannot prevent it.
On the other hand, Chrome does not start autoscroll when a modifier is pressed.
This means that our users may not be able to use middle click with modifiers
if web apps do not call `preventDefault()` as expected. So, this difference
is a potential risk of web-compat.
Therefore, this patch makes `AutoScrollChild` stop starting autoscroll if
`Shift` key is pressed.
Differential Revision: https://phabricator.services.mozilla.com/D119253
When middle mouse paste is enabled and middle click occurs in an editable
content or it's in a document whose `designMode` is `on`, we shouldn't start
the autoscrolling because the click must be intended for pasting clipboard
content or primary selection to the position.
Differential Revision: https://phabricator.services.mozilla.com/D117987
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
Currently, for auto scroller, when a `mousedown` happens, a possible run order is that
`mousedown(parent process)` -> `scroll stopped (parent process)` ->
`mousedown(child process)`, so that the last mousedown(child process)
would start the scrolling again.
This patch adds a new check to the last `mousedown(child process)`
handler, to not starting the scrolling again if preventClickEvent has
been called on this event.
Differential Revision: https://phabricator.services.mozilla.com/D111885
We're sending two messages (one out, one in) when we switch between
menuitems for example. The patch by Matt caused us to sometimes paint in
between that period of time and made this noticeable, but it seems
pretty bad regardless.
Send messages only when the mouse enters / leaves the popup, which is
what the code was intended to do.
Differential Revision: https://phabricator.services.mozilla.com/D112035
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
When active tab loads `about:*` which is in the chrome process, focused element
is null. Therefore, the check whether the browser element of `AutoScrollParent`
is active tab or not does not work as expected. And the new check was added
for web apps which don't call `preventDefault()` properly after opening new
tab of a middle mouse button click. So, our chrome document must not require
this hack. So, we keep the old behavior when the browser is not a remote one.
Differential Revision: https://phabricator.services.mozilla.com/D110069
Selection may be null if the page got hidden in e.g., the afterprint
event listener or somewhere else.
Add a try catch for good measure, assuming there's no selection is
always safe.
I'll try to get an automated test-case for this working, though it might
be tricky.
Depends on D109714
Differential Revision: https://phabricator.services.mozilla.com/D109715
This fix is in three parts:
- ensure SelectParent's concept of the 'UA style' of the dropdown matches with the dark theme.
This ensures that we don't ignore black-text-on-white-bg page styles in dark mode because
they match the default styles, and end up with unreadable text because only one of the
foreground/background colours exactly matches the UA style. This isn't a complete fix for
the problem of contrast in this menu, but that isn't really in-scope here...
- ensure the foreground colour that the win10 menu sets is on the menupopup, rather than the
scrollbox. On the scrollbox it would cause the individual menuitems to inherit that, rather
than the colour set by SelectParent on the menupopup.
- fix a broken variable reference for the foreground colour for hovered (_menuactive) items in
menu.css, without which the foreground colour on the hover/active item was still wrong.
Differential Revision: https://phabricator.services.mozilla.com/D109751
Rashelle Hopkins
Jonathan Watt
Butkovits Atila
Emilio Cobos Álvarez
Evgenia Kotovich
Geoff Lankow
Sebastian Hengst
raquelvargas
Sandor Molnar
Gabriel Luong
Narcis Beleuzu
Timothy Nikkel
owlishDeveloper
Noemi Erli
Gijs Kruitbosch
Makoto Kato
Daniel Holbert
Iulian Moraru
Masayuki Nakano
Nika Layzell
Mark Striemer
Henri Sivonen
Dorel Luca
Kartikaya Gupta
Neil Deakin
Sean Feng