Split off of Bug 1590894
Rename these to support unprefixed version
Also add alias to keep compatibility
Differential Revision: https://phabricator.services.mozilla.com/D50989
--HG--
extra : moz-landing-system : lando
This change makes opaqueness a boolean per layer again. The opaque region is
currently only used by the temporary WebRender code; the future WebRender code
won't use it. Removing this support simplifies the code and makes it easier to
implement clipping.
Differential Revision: https://phabricator.services.mozilla.com/D50722
--HG--
extra : moz-landing-system : lando
It's not the kind of thing we want people to allow observing, generally, and
even less so the kind of thing that we may want people to rely on.
Move internal callers (all of them tests) to a new DOMWindowUtils.paintCount
method.
Differential Revision: https://phabricator.services.mozilla.com/D50817
--HG--
extra : moz-landing-system : lando
The patch permits to resize compositor window's size after ::SetParent() call to prevent a conflict between ::SetParent() and ::SetWindowPos(). Then it triggers a composite after SetParent() call to resize compositor window correctly.
Differential Revision: https://phabricator.services.mozilla.com/D49884
--HG--
extra : moz-landing-system : lando
`nsXULAppInfo::GetUserCanElevate` can reuse `GetElevationType` and we can remove
`VistaTokenElevationType` definition.
Differential Revision: https://phabricator.services.mozilla.com/D49691
--HG--
extra : moz-landing-system : lando
I discovered this while improving `ScrollFrameHelper::IsPhysicalLTR()`
in Part 1. Our code base needs a notion of physical direction. Let's add
it to WritingMode.
Differential Revision: https://phabricator.services.mozilla.com/D49818
--HG--
extra : moz-landing-system : lando
This obviously only improves the situation when a subsequent window is the
same size as the last window that was opened.
Differential Revision: https://phabricator.services.mozilla.com/D50527
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
Didn't want to remove all the WebAuthn and dynamic toolbar code so I left it
there in case it's useful in the future.
Differential Revision: https://phabricator.services.mozilla.com/D49588
--HG--
extra : moz-landing-system : lando
Forwarding keyboard focus/blur events to VR browser that runs at another process. We will need to set these events in VR shmem, then VR host can receive these states from other process.
Differential Revision: https://phabricator.services.mozilla.com/D48903
--HG--
extra : moz-landing-system : lando
By getting the right screen size we can shrink the popup menus which overflows
the screen size under Wayland. The ScreenManager does not help us, because we
can't get absolute window position, but we can use gdk_display_get_monitor_at_window
and gdk_monitor_get_workarea to get the correct screen rectangle.
Differential Revision: https://phabricator.services.mozilla.com/D49289
--HG--
extra : moz-landing-system : lando
We use SystemParametersInfo to get the current system scroll wheel settings when we process scrollwheel movement in the content process. We need to remove SystemParametersInfo for sandboxing the content process so this code changes the plugin behavior to cache the system wheel settings. We do this by 1) sending wheel settings to the plugin whenever a plugin takes focus and 2) forwarding wheel settings update messages from Windows to the currently focused plugin.
Differential Revision: https://phabricator.services.mozilla.com/D47938
--HG--
extra : moz-landing-system : lando
By getting the right screen size we can shrink the popup menus which overflows
the screen size under Wayland. The ScreenManager does not help us, because we
can't get absolute window position, but we can use gdk_display_get_monitor_at_window
and gdk_monitor_get_workarea to get the correct screen rectangle.
Differential Revision: https://phabricator.services.mozilla.com/D49289
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
With the additional tests running, task times increase; I have added one
more test chunk for android mochitest-plain.
These tests were identified from a random sampling of mochitest manifests;
I intend to enable more mochitests in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D48912
--HG--
extra : moz-landing-system : lando
Usually it covers a different area than the window's ChildView. But in some cases
it can overlap with the ChildView, and in those cases, it's better if the
ChildView is on top.
Differential Revision: https://phabricator.services.mozilla.com/D49332
--HG--
extra : moz-landing-system : lando
We can't set wl_egl_window from widget code as it must match GL rendering pipeline,
so let compositor to set the egl window size.
Depends on D49136
Differential Revision: https://phabricator.services.mozilla.com/D49137
--HG--
extra : moz-landing-system : lando
wl_egl_window size must exactly march GL rendering pipeline setting.
Compositor and widget can have different window sizes during window resize when widget
is resized faster than layout can render. Firefox window is rendered misplaced then
and it's "jumping" as layout size is behind toolkit size.
Differential Revision: https://phabricator.services.mozilla.com/D49136
--HG--
extra : moz-landing-system : lando
We can't set wl_egl_window from widget code as it must match GL rendering pipeline,
so let compositor to set the egl window size.
Depends on D49136
Differential Revision: https://phabricator.services.mozilla.com/D49137
--HG--
extra : moz-landing-system : lando
wl_egl_window size must exactly march GL rendering pipeline setting.
Compositor and widget can have different window sizes during window resize when widget
is resized faster than layout can render. Firefox window is rendered misplaced then
and it's "jumping" as layout size is behind toolkit size.
Differential Revision: https://phabricator.services.mozilla.com/D49136
--HG--
extra : moz-landing-system : lando
We could put this change itself behind a pref too, if we considered that worth
it. But probably not so.
Differential Revision: https://phabricator.services.mozilla.com/D48010
--HG--
extra : moz-landing-system : lando
Web Share base implementation just of DOM stuff - working together with @saschanaz.
@Baku, we would greatly appreciate your review.
-Nika, as she is traveling.
Differential Revision: https://phabricator.services.mozilla.com/D44598
--HG--
extra : moz-landing-system : lando
This was already working for toolbars, but it wasn't working for the titlebar in windows that
actually have a real separate titlebar.
All our windows use NSFullSizeContentViewWindowMask, so we no longer get this behavior for free.
In windows with titlebars, the titlebar area is covered with a TitlebarGradientView, so that's
where we need to handle the double clicks.
Differential Revision: https://phabricator.services.mozilla.com/D48593
--HG--
extra : moz-landing-system : lando
Also rename existing utility functions to reflect that they are for VP8 only.
Differential Revision: https://phabricator.services.mozilla.com/D47369
--HG--
extra : moz-landing-system : lando
When high contrast mode is enabled, title bar is drawn as transparent and on-client area rendering by DWM is shown. But when compositor window in GPU process is used, the on-client area rendering was not shown. To address the proboem, window needs to be cleard as transparent and SwapChain of compositor window needs to be DXGI_ALPHA_MODE_PREMULTIPLIED.
WinCompositorWidget::mTransparencyMode is changed to atomic, since it is accessed from compositor thread and render thread.
Differential Revision: https://phabricator.services.mozilla.com/D48302
--HG--
extra : moz-landing-system : lando
Chrome and old Edge at least seem to have this behavior, and this way the testcase on the bug doesn't trigger click anymore since
we enter dnd mode and get dragleave etc. events.
Manually tested on linux and Windows, and annyg tested on Mac
Update test_dragstart.html's draggable=true test to follow the pattern used by other tests
Differential Revision: https://phabricator.services.mozilla.com/D48208
--HG--
extra : moz-landing-system : lando
Also rename existing utility functions to reflect that they are for VP8 only.
Differential Revision: https://phabricator.services.mozilla.com/D47369
--HG--
extra : moz-landing-system : lando
Chrome and old Edge at least seem to have this behavior, and this way the testcase on the bug doesn't trigger click anymore since
we enter dnd mode and get dragleave etc. events.
Manually tested on linux and Windows, and annyg tested on Mac
Differential Revision: https://phabricator.services.mozilla.com/D48208
--HG--
extra : moz-landing-system : lando
This is related to bug 1530649. When using <span> element with contentedtiable,
we won't insert <br> element at last. When Korean IME on macOS commits
composition by space key, composition string has space.
Gekco removes U+0020 space when it is last character into editing host. To keep
whitespace, we have to replace with NBSP when it is last.
Differential Revision: https://phabricator.services.mozilla.com/D48146
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando