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
This _almost_ fixes layout/reftests/forms/input/range/auto-size.html. It still
fails because of the variable-width track size :/
Differential Revision: https://phabricator.services.mozilla.com/D65673
--HG--
extra : moz-landing-system : lando
So when I simply set the property on the window and flushed the display, I didn't
manage to get the desired effect.
Then I found this 'gxtuner' project that sends an event, which is correctly
picked up by Gnome and hopefully others.
Differential Revision: https://phabricator.services.mozilla.com/D65650
--HG--
extra : moz-landing-system : lando
See the comment for the sadness. Otherwise there was quite a lot of fuzz to
annotate.
Differential Revision: https://phabricator.services.mozilla.com/D65666
--HG--
extra : moz-landing-system : lando
These attribute and method were added for media control in Fennec and it seems we forgot to clean them.
Differential Revision: https://phabricator.services.mozilla.com/D65259
--HG--
extra : moz-landing-system : lando
We were stroking the ellipse which strokes through the middle of the path,
meaning that it overflowed by one css pixel around the circle.
Differential Revision: https://phabricator.services.mozilla.com/D65633
--HG--
extra : moz-landing-system : lando
This should be less confusing. This is not supported outside of chrome:// or
user-agent stylesheets so we can name this however we want.
Differential Revision: https://phabricator.services.mozilla.com/D65605
--HG--
extra : moz-landing-system : lando
<select style="-webkit-appearance: menulist-button;">
<option>Foo</option>
</select>
Should look like a menulist without a button, not like a button :)
This kinda sucks and is confusing, see bug 1428676
Differential Revision: https://phabricator.services.mozilla.com/D65604
--HG--
extra : moz-landing-system : lando
We don't advertise these as supported from ThemeSupportsWidget, so they're just
noise.
Also most of these are only useful in chrome pages anyway.
Differential Revision: https://phabricator.services.mozilla.com/D65590
--HG--
extra : moz-landing-system : lando
Bug 1615026 introduced some coordinate space change which I didn't intend.
NSRectToSnappedRect does what we want instead.
Differential Revision: https://phabricator.services.mozilla.com/D65519
--HG--
extra : moz-landing-system : lando
This is based on a patch by robert.mader
This is supposed to be a minimal patchset to make Firefox work on
Mutter 3.36 in a similar fassion as on 3.34. The changes should
be compatible with any Wayland compositor, especially those that
do similar agressive culling and frame callback reduction.
While technically non-optimal, they should work as a short time
solution.
1.: Do not commit the toplevel surface in moz_container_move. Instead
use gdk_window_invalidate_rect, which (hopefully) triggers a surface
commit as well while not interfering in the order of commands. The is
necessary as the previous commit would commit invalid state in certain
scenarios (like fullscreening).
This fixes broken fullscreening.
2.: Do not set an opaque region on containers if that would cover the
whole toplevel surface. This works around problems concerning mouse
input responsiveness, as a completely covered toplevel surface might
not get frame callbacks any more, but we currently rely on it to process
input events like mouse movements.
3.: Only set an opaque region on the toplevel surface when maximized.
While the toplevel opaque region is actually redundant as long as the
content surface has an opaque region set, we need it for workaround 2.
But we want to unset it when not needed as occasianally it is not in
sync, creating glitches when e.g. unmaximizing.
Differential Revision: https://phabricator.services.mozilla.com/D65476
--HG--
extra : moz-landing-system : lando
...and properly pixel-snap while at it, as otherwise my test would fail fuzzily.
Stroke() paints a stroke from the middle of the path, so it'll paint
one-half-of-the-width outside of the rect.
We need to deflate it by half the border width so that the stroke covers exactly
the area we want.
Differential Revision: https://phabricator.services.mozilla.com/D65422
--HG--
extra : moz-landing-system : lando
This is supposed to be a minimal patchset to make Firefox work on
Mutter 3.36 in a similar fassion as on 3.34. The changes should
be compatible with any Wayland compositor, especially those that
do similar agressive culling and frame callback reduction.
While technically non-optimal, they should work as a short time
solution.
1.: Do not commit the toplevel surface in `moz_container_move`. Instead
use `gdk_window_invalidate_rect`, which (hopefully) triggers a surface
commit as well while not interfering in the order of commands. The is
necessary as the previous commit would commit invalid state in certain
scenarios (like fullscreening).
This fixes broken fullscreening.
2.: Do not set an opaque region on containers if that would cover the
whole toplevel surface. This works around problems concerning mouse
input responsiveness, as a completely covered toplevel surface might
not get frame callbacks any more, but we currently rely on it to process
input events like mouse movements.
3.: Only set an opaque region on the toplevel surface when maximized.
While the toplevel opaque region is actually redundant as long as the
content surface has an opaque region set, we need it for workaround 2.
But we want to unset it when not needed as occasianally it is not in
sync, creating glitches when e.g. unmaximizing.
Differential Revision: https://phabricator.services.mozilla.com/D64966
--HG--
extra : moz-landing-system : lando
Since bug 440895, we've got support in sessionstore to support restoring a window
to their respective virtual desktops.
This patch using a deprecated GDK API. It builds and works fine, but not without
compilation warnings.
Differential Revision: https://phabricator.services.mozilla.com/D65105
--HG--
extra : moz-landing-system : lando
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
--HG--
rename : netwerk/cookie/CookieSettings.cpp => netwerk/cookie/CookieJarSettings.cpp
rename : netwerk/cookie/nsICookieSettings.idl => netwerk/cookie/nsICookieJarSettings.idl
extra : moz-landing-system : lando
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
--HG--
extra : moz-landing-system : lando
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
--HG--
extra : moz-landing-system : lando
1. Use GBM map/unmap API correctly
The documentation of gbm_bo_unmap describes the second argument as
"map_data opaque ptr returned from prior gbm_bo_map",
which refers to the pointer written to the map_data location by gbm_bo_map,
not the pointer *returned* by gbm_bo_map.
This fixes crashes with widget.wayland-dmabuf-textures.enabled
on the Mesa RadeonSI driver.
2. Set modifier to invalid on the fallback code path
This fixes fCreateImage failure, allowing actual rendering
to happen.
(mBufferModifier was not set to DRM_FORMAT_MOD_INVALID,
so unsupported attributes were added to the CreateImage call)
Differential Revision: https://phabricator.services.mozilla.com/D65239
--HG--
extra : moz-landing-system : lando
This allows testing much more easily.
There are some edge cases with native theme changes and such (ThemeChanged and
co assume there's only one theme per process). But I don't think they matter
much for our use cases.
Differential Revision: https://phabricator.services.mozilla.com/D65162
--HG--
extra : moz-landing-system : lando
When deleting text by backspace key of VKB, VKB might use `InputConnection.setComposingText`, not using KeyEvent. So although we dispatch dummy key event, the order of events is incorrect. We should dispatch keydown before input event.
Differential Revision: https://phabricator.services.mozilla.com/D64892
--HG--
extra : moz-landing-system : lando
In most cases, `InputEvent.getTargetRange()` of `beforeinput` event should
return `Selection` ranges at dispatching the event.
This patch also handles special cases.
* composition change - target range should be the previous composition string
which will be replaced with new composition string.
* replace text - target range should be the replace range. This is used by
spellchecker.
* drop - target range should be the drop point.
However, the other exception is not handled by this patch. That is, deletions.
The target range(s) should be the range(s) which will be removed. In most
cases, they also matches selection ranges, but may be extended to:
* surrogate pair boundary
* grapheme cluster boundary like complex emoji
* word/line deletion deletion
* `Backspace` or `Delete` from collapsed selection
* to end of unnecessary whitespaces
For supporting these cases, we need to separate
`HTMLEditor::HandleDeleteSelection()` and its helper methods and helper class
to range computation part and modifying the DOM tree part. Of course, it
requires big changes and `InputEvent.getTargetRanges()` may be important for
feature detection of `beforeinput` event so that we should put off the big
changes to bug 1618457.
Differential Revision: https://phabricator.services.mozilla.com/D64730
--HG--
extra : moz-landing-system : lando
`InputEventOptions` should be able to take target ranges for `beforeinput`
event. However, it requires to include `StaticRange.h` from `nsContentUtils.h`
even though most `nsContentUtils.h` users don't need it. Therefore, this patch
moves it from `nsContentUtils.h` to new header file.
And makes `nsContentUtils::DispatchInputEvent()` moves the target ranges
from `InputEventOptions` to `InternalEditorInputEvent`.
Differential Revision: https://phabricator.services.mozilla.com/D64729
--HG--
extra : moz-landing-system : lando
`InputEvent.getTargetRanges()` can be used only when event type is
`beforeinput`. So, it may be used for feature detection of `beforeinput`
event because Chrome does not implement `onbeforeinput` event handler attribute.
Therefore, this patch makes it behind the pref for `beforeinput` event.
Differential Revision: https://phabricator.services.mozilla.com/D64728
--HG--
extra : moz-landing-system : lando
Maybe we should be using some native color, but the background for that is white
in my testing, so probably not, or at least probably it can be a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D64816
--HG--
extra : moz-landing-system : lando
David Parks
Martin Stransky
Andrew Osmond
Masayuki Nakano
Mark Banner
Emilio Cobos Álvarez
Sebastian Hengst
Mike de Boer
Alastor Wu
Ciure Andrei
Noemi Erli
Coroiu Cristina
Jeff Muizelaar
Robert Mader
Tim Huang
Makoto Kato
Csoregi Natalia
Greg V
Kartikaya Gupta
Mihai Alexandru Michis
Stephen A Pohl