Let's use GtkInputPurpose and GtkInputHints by inputmode for software keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D67771
--HG--
extra : moz-landing-system : lando
Let's use GtkInputPurpose and GtkInputHints by inputmode for software keyboard.
Depends on D67770
Differential Revision: https://phabricator.services.mozilla.com/D67771
--HG--
extra : moz-landing-system : lando
To correctly implement this, it must be known on instantiation whether E is
copy-constructible, which is not the case if only a forward declaration is
available. This can be resolved either by making sure a full definition of E is
available, which is preferable. But in cases where this is not (easily) possible,
the information can be explicitly provided by the MOZ_DECLARE_COPY_CONSTRUCTIBLE
and MOZ_DECLARE_NON_COPY_CONSTRUCTIBLE macros. In particular, declarations for
IPDL-declared types are added to nsTArray.h itself, like it was already done
for MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR.
Differential Revision: https://phabricator.services.mozilla.com/D66244
--HG--
extra : moz-landing-system : lando
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
The bugs is reproducible only with all Korean IMEs of Apple only on Catalina.
Until Apple fixes the bug, we should not allow the Korean IMEs to consume
mouse events. (I think that we should keep notifying all mouse events for
backward compatibility.)
Differential Revision: https://phabricator.services.mozilla.com/D67285
--HG--
extra : moz-landing-system : lando
Mutter 3.36 requests exact match of wl_surface/wl_subsurface size so we need to respect
wl_surface size (GtkWidget size) and create a wl_subsurface with the same size.
Differential Revision: https://phabricator.services.mozilla.com/D67137
--HG--
extra : moz-landing-system : lando
On high contrast themes, we avoid using the colors from the author to ensure
contrast.
We allow the border-style though, and that unfortunately means that:
<input type=text style="border: 1px solid black">
Ends up rendering like:
<input type=text style="border-style: solid; border-width: 1px">
Which for a theme with a white background means that we'll render a white
border which users can't see, and is unfortunate.
Hard-code these colors, as using the background color for the light variant
doesn't seem right anyway, and the dark variant was hard-coded already.
These colors are taken from the cocoa widget. You can see the change in colors
with something like:
<input type=text style="border-width: 2px">
For default themes it makes the colors a bit less subtle. But I don't think it
matters all that much in practice since the fallback unthemed border is very
rare on the web these days.
The rendering here is still not great, to be clear (we may want to tweak the
high-contrast heuristics here), but it's way better than invisible borders.
Differential Revision: https://phabricator.services.mozilla.com/D67127
--HG--
extra : moz-landing-system : lando
On high contrast themes, we avoid using the colors from the author to ensure
contrast.
We allow the border-style though, and that unfortunately means that:
<input type=text style="border: 1px solid black">
Ends up rendering like:
<input type=text style="border-style: solid; border-width: 1px">
Which for a theme with a white background means that we'll render a white
border which users can't see, and is unfortunate.
Hard-code these colors, as using the background color for the light variant
doesn't seem right anyway, and the dark variant was hard-coded already.
These colors are taken from the cocoa widget. You can see the change in colors
with something like:
<input type=text style="border-width: 2px">
For default themes it makes the colors a bit less subtle. But I don't think it
matters all that much in practice since the fallback unthemed border is very
rare on the web these days.
The rendering here is still not great, to be clear (we may want to tweak the
high-contrast heuristics here), but it's way better than invisible borders.
Differential Revision: https://phabricator.services.mozilla.com/D67127
--HG--
extra : moz-landing-system : lando
On high contrast themes, we avoid using the colors from the author to ensure
contrast.
We allow the border-style though, and that unfortunately means that:
<input type=text style="border: 1px solid black">
Ends up rendering like:
<input type=text style="border-style: solid; border-width: 1px">
Which for a theme with a white background means that we'll render a white
border which users can't see, and is unfortunate.
Hard-code these colors, as using the background color for the light variant
doesn't seem right anyway, and the dark variant was hard-coded already.
These colors are taken from the cocoa widget. You can see the change in colors
with something like:
<input type=text style="border-width: 2px">
For default themes it makes the colors a bit less subtle. But I don't think it
matters all that much in practice since the fallback unthemed border is very
rare on the web these days.
The rendering here is still not great, to be clear (we may want to tweak the
high-contrast heuristics here), but it's way better than invisible borders.
Differential Revision: https://phabricator.services.mozilla.com/D67127
--HG--
extra : moz-landing-system : lando
`PlaybackState` and `MediaSessionPlaybackState` are actually quite similar, and we don't want to have to many states to confuse reader and do unnecessary tranform between two states. Therefore, replaceing `PlaybackState` with `MediaSessionPlaybackState`.
Differential Revision: https://phabricator.services.mozilla.com/D66342
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
Gecko don't commit composition when software keyboard calls
InputConnection.finishComposingText. It is incompatible with Blink's behaviour.
BaseInputConnection.finishComposingText() implementation is the following.
1. Begin batch edit.
2. Remove all composition span flag.
3. End batch edit.
So if no composition after batch edit is finished, we should commit it on Gecko
to synchronize composition state.
Differential Revision: https://phabricator.services.mozilla.com/D66370
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
CompositorVsyncDispatcher holds a reference to the VsyncSource, so it must be informed on change.
Differential Revision: https://phabricator.services.mozilla.com/D65878
--HG--
extra : moz-landing-system : lando
This is similar to a change that landed directly into 74. We don't want to
roll-out to these users yet and we don't want to have to think about it every
release.
Differential Revision: https://phabricator.services.mozilla.com/D66453
--HG--
extra : moz-landing-system : lando
Changes:
Due to scrollbar and other UI element changes in linux1804 this test was permafailing and was marked as such.
Now that migration has completed for mochitest-plain, re-enable the test with updated pixel count expectations.
Differential Revision: https://phabricator.services.mozilla.com/D66647
--HG--
extra : moz-landing-system : lando
This patch also tweaks the behavior on Ubuntu Unity slightly to work with the
adaptive workspaces.
Differential Revision: https://phabricator.services.mozilla.com/D66431
--HG--
extra : moz-landing-system : lando
