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
When called on a non-main thread, [NSAnimationContext beginGrouping] calls [CATransaction activateBackground:].
There's a chance that doing so might help with some of the crashes we're seeing during [CATransaction commit].
Differential Revision: https://phabricator.services.mozilla.com/D47854
--HG--
extra : moz-landing-system : lando
We were testing the dwFlags field against TOUCHINPUTMASKF_CONTACTAREA, when
in fact that is meant to be tested against the dwMask field.
Differential Revision: https://phabricator.services.mozilla.com/D47962
--HG--
extra : moz-landing-system : lando
Before this patch, we only considered the primary screen when deciding
whether or not WebRender should be enabled. This is problematic for
Intel users where we don't want to turn on WebRender for large screens;
several small screens are just as bad as one large screen. Now we sum
the pixel count for all the screens when making this decision.
Differential Revision: https://phabricator.services.mozilla.com/D46066
--HG--
extra : moz-landing-system : lando
Under Wayland it is possible to add only one popup window
to a parent window. If we try to attach another popup to the window,
the GTK refuses to do that. This can happen when the previous popup
has not yet been hidden while the new popup is showing (in some cases
the nsWindow::Show(false) for the previous popup is not called before
nsWindow::Show(true) for the new one).
We deal with it by hiding wayland popups which are no longer in the
XULPopupManager (PM) before showing a new one. We only do that for
the main menu popups or context (sub)menus. We cannot use PM to check
for the panel popup content like Folder dropdown in Edit Bookmark panel
or WebRTC microphone/video source dropdown. In that case we simply use
the last shown popup as a transient for the new one or the toplevel window.
Differential Revision: https://phabricator.services.mozilla.com/D47610
--HG--
extra : moz-landing-system : lando
When clicking native toast on Windows 10, focus moves to another process,
So we have to set focus on Firefox process.
Differential Revision: https://phabricator.services.mozilla.com/D47398
--HG--
extra : moz-landing-system : lando
Under Wayland it is possible to add only one popup window
to a parent window. If we try to attach another popup to the window,
the GTK refuses to do that. This can happen when the previous popup
has not yet been hidden while the new popup is showing (in some cases
the nsWindow::Show(false) for the previous popup is not called before
nsWindow::Show(true) for the new one).
We deal with it by hiding wayland popups which are no longer in the
XULPopupManager (PM) before showing a new one. We only do that for
the main menu popups or context (sub)menus. We cannot use PM to check
for the panel popup content like Folder dropdown in Edit Bookmark panel
or WebRTC microphone/video source dropdown. In that case we simply use
the last shown popup as a transient for the new one or the toplevel window.
Differential Revision: https://phabricator.services.mozilla.com/D47610
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
I've hit this in one of my try runs and looks trivial to fix.
The already_AddRefed destructor asserts when leaked.
We should just not allow to let it go out of scope without moving the pointer.
Differential Revision: https://phabricator.services.mozilla.com/D46942
--HG--
extra : moz-landing-system : lando
The `const` qualifier on `mVersion` was preventing move and copy, which we
now need this class to support.
Depends on D43158
Differential Revision: https://phabricator.services.mozilla.com/D43159
--HG--
extra : moz-landing-system : lando