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
I've left checkbox / radio / range-thumb alone because they don't have borders
on gtk either. We need this for the next patch to fix our test.
In particular, our combination of padding + no border means that
sanityEventUtils tries to hit an <input>, but it hits the anonymous scrollable
element instead, and asserts that it doesn't.
I don't think that test is particularly correct, but implementing
GetWidgetBorder works around it, and seems like the right thing to do anyways.
Differential Revision: https://phabricator.services.mozilla.com/D66240
--HG--
extra : moz-landing-system : lando
I've left checkbox / radio / range-thumb alone because they don't have borders
on gtk either. We need this for the next patch to fix our test.
In particular, our combination of padding + no border means that
sanityEventUtils tries to hit an <input>, but it hits the anonymous scrollable
element instead, and asserts that it doesn't.
I don't think that test is particularly correct, but implementing
GetWidgetBorder works around it, and seems like the right thing to do anyways.
Differential Revision: https://phabricator.services.mozilla.com/D66240
--HG--
extra : moz-landing-system : lando
Bug 1419488 moved AudioSession shutdown to a background thread on Windows 7 because it was leading to shutdown timeouts there. Since then, audio seems to be inspiring timeouts on other versions of Windows as well. This patch extends the Windows 7 work to all versions of Windows.
Bug 1430907 is removing AudioSession from content processes. This is the only place we have seen these crashes but AudioSession is also used in the main and plugin processes, so we want this patch to preempt issues with those processes.
Differential Revision: https://phabricator.services.mozilla.com/D64465
--HG--
extra : moz-landing-system : lando
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
The reason of intermittent failure of `test_bug656379-2.html` is, synthesized
`mousemove` event coming from the parent process causes `mouseout` and
`mouseleave` events of the last synthesized `mousemove` in the test. The
reason is, synthesized `mousemove` for tests makes `PresShell` in the content
process record the cursor location, but won't make it `PresShell` in the
parent process do it. Therefore, parent process may synthesize `mousemove`
event for the system cursor position which does not match with the synthesized
mouse location in the content process. Therefore, `:hover` state may be
updated unexpectedly.
This patch makes `WidgetEvent::mFlags` have a flag to indicate whether it
came from another process. Then, makes `PresShell::HandleEvent()` ignore
synthesized `mousemove` events coming from another process only when the
recorded mouse location was set by a mouse event synthesized for tests.
Differential Revision: https://phabricator.services.mozilla.com/D65282
--HG--
extra : moz-landing-system : lando
This is very basic, and just uses the button colors. Did this because I thought
that it was going to help me fix one test but it didn't in the end, feel free to
reject, or to tell me to land the cleanup somewhere else :)
Depends on D65674
Differential Revision: https://phabricator.services.mozilla.com/D65675
--HG--
extra : moz-landing-system : lando
Otherwise the rendering of stuff like:
<input type=range style="height: 300px">
Makes no sense. So this is closer to other widgets, and also happens to fix the
only test which is a real regression from non-native widget :)
Depends on D65673
Differential Revision: https://phabricator.services.mozilla.com/D65674
--HG--
extra : moz-landing-system : lando
Martin Stransky
Masayuki Nakano
Michael
Emilio Cobos Álvarez
Marc Streckfuss
Brindusan Cristian
Narcis Beleuzu
Jeff Muizelaar
Chris Fronk
alwu
Kenny Levinsen
Mihai Alexandru Michis
Simon Giesecke
Bogdan Tara
Makoto Kato
Coroiu Cristina
James Willcox
Jessie Bonisteel
Andreea Pavel
Mike Conley
Cosmin Sabou
Edwin Takahashi
Marco Zehe
Mike de Boer
Xidorn Quan
Boris Zbarsky
Dorel Luca
David Parks
Andrew Osmond
Mark Banner