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
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
This change introduces plumbing for communicating with the GPU process through
VRShMem while bootstrapping Firefox for creating a window with Firefox Reality.
Test impact shows a fabricated value returned for the texture handle in VRShMem.
Differential Revision: https://phabricator.services.mozilla.com/D41383
--HG--
extra : moz-landing-system : lando
Even if we don't have a root displayport, the composition size is still used for
displayport margins calculations. For extremely tall iframes, this will create
a displayport that is way to big. We should instead report a composition size that
is equivalent to the visible rect for OOP-iframes.
Differential Revision: https://phabricator.services.mozilla.com/D34528
--HG--
extra : rebase_source : 1f43cb16a0841eb3cd892401c83a46d56276cf2e
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
This is a large patch that contains all of the core changes for
renderroot splitting.
Differential Revision: https://phabricator.services.mozilla.com/D20701
--HG--
extra : moz-landing-system : lando
This cleans up a bit and allows us to be smarter about which cursors
should we allow from content or what not, which will help with bug 1445844 and
co.
Differential Revision: https://phabricator.services.mozilla.com/D16711
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
We've added nsIWidget::GetDesktopToDeviceScaleByScreen which will return scale factor of the newly placed window
according to its position on the display. This change is to move implementation to the nsIWidget derived classes.
We need that for GTK Wayland, because on the Wayland we cannot determine absolute position of the window, we
need to use parent's window scale factor. For other platforms the GetDesktopToDeviceScaleByScreen is implemented
in nsBaseWidget.
Differential Revision: https://phabricator.services.mozilla.com/D7290
--HG--
extra : moz-landing-system : lando
We've added nsIWidget::GetDesktopToDeviceScaleByScreen which will return scale factor of the newly placed window
according to its position on the display. This change is to move implementation to the nsIWidget derived classes.
We need that for GTK Wayland, because on the Wayland we cannot determine absolute position of the window, we
need to use parent's window scale factor. For other platforms the GetDesktopToDeviceScaleByScreen is implemented
in nsBaseWidget.
Differential Revision: https://phabricator.services.mozilla.com/D7290
--HG--
extra : moz-landing-system : lando
We've added nsIWidget::GetDesktopToDeviceScaleByScreen which will return scale factor of the newly placed window
according to its position on the display. This change is to move implementation to the nsIWidget derived classes.
We need that for GTK Wayland, because on the Wayland we cannot determine absolute position of the window, we
need to use parent's window scale factor. For other platforms the GetDesktopToDeviceScaleByScreen is implemented
in nsBaseWidget.
Differential Revision: https://phabricator.services.mozilla.com/D7290
--HG--
extra : moz-landing-system : lando
The framework to simulate the setting change works as following;
- nsIDOMWindowUtils.setPrefersReducedMotion() calls an IPC function which ends
up calling nsChildView::SetPrefersReducedMotion() in the parent process
- nsChildView::SetPrefersReducedMotion() sets the given value into
nsLookAndFeel::mPrefersReducedMotionCached just like we set the value queried
via NSWorkspace.accessibilityDisplayShouldReduceMotion in the parent process
and send a notification which is the same notification MacOSX sends when the
system setting changed
- Normally the cached value is cleared before quering new values since the
cache value is stale, but in this case the value is up-to-date one, so
nsChildView::SetPrefersReducedMotion() tells that we don't need to clear the
cache, and nsIDOMWindowUtils.resetPrefersReducedMotion() resets that state
of 'we don't need to clear the cache'
There are two test cases with the framework in this commit, one is just setting
the value and checking the value queried by window.matchMedia. The other one is
receiving 'change' event and checking the value of the event target.
Note that to make this test works the patch for bug 1478212 is necessary since
the test runs in an iframe.
Depends on D5003
Differential Revision: https://phabricator.services.mozilla.com/D5004
--HG--
extra : moz-landing-system : lando
The test case in this patch fails without the proper fix in the first patch
in this patch series.
In this patch two new nsIDOMWindowUtils APIs are introduced to change the
system font settins in tests. Currently the APIs work only on GTK+ platform.
Also to work the test case properly we need to open a new XUL window because we
don't propagate font changes into descendant documents yet (bug 1478212).
MozReview-Commit-ID: 4OLxEkEuF8d
--HG--
extra : rebase_source : 683e64f07c4d8820e5499d8c15b90975618559b8
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
Key of TextCompositionArrary to search composition on widget is native IME
context. However, if TextInputProcessor dispatches composition events via
TextEventDispatcher, TextEventDispatcher::InitEvent() sets native IME context
of dispatching composition events to pseudo IME context (that's raw pointer
of TextEventDispatcher and process ID).
IMEStateManager::DispatchCompositionEvent() looks for existing TextComposition
with native IME context stored in WidgetCompositionEvent before dispatching
an event. However, after dispatching it, it looks for remaining TextComposition
instance with widget stored in WidgetCompositionEvent. Then,
TextCompositionArrary::IndexOf(nsIWidget*) will look for an instance with
the result of nsIWidget::GetNativeIMEContext() and this never returns actual
native IME context. Therefore, IMEStateManager::DispatchCompositionEvent()
always fails to remove TextComposition instance from the array even after
a test composition is finished.
This patch moves nsIWidget::GetNativeIMEContext() to nsBaseWidget to refer
nsBaseWidget::mTextEventDispatcher makes it return pseudo IME context if
TextInputProcessor has input transaction. Therefore, IMEStateManager becomes
always removes TextComposition from the array when every composition ends.
MozReview-Commit-ID: H1PCtPjBYJR
--HG--
extra : rebase_source : cbb3f3aae9954d65135d3840be8974fa30c4f7ff
By the proposal from Google, <https://github.com/w3c/uievents/issues/147>,
Chromium treat AltRight key as "AltGraph" modifier if the keyboard layout
has AltGr key.
When AltRight key is pressed with a keyboard layout which has AltGr key,
modifiers should as following:
1. "keydown" for ControlLeft:
ctrlKey: true, altKey: false, getModifierState("AltGraph"): false
2. "keydown" for AltRight:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
3. Some "keydown", "keypress" and "keyup" events:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
4. "keyup" for ControlLeft:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
5. "keyup" for AltRight:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): false
So, only when the preceding "keydown" event for ControlLeft, ctrlKey should
be set to true as usual. However, after AltRight key is pressed actually,
we should treat "AltGraph" modifier is true and both ctrlKey and altKey
should be set to false for web apps can handle text input normally.
So, MODIFIER_ALTGRAPH and MODIFIER_CONTROL/MODIFIER_ALT should not be set
at the same time.
This patch makes ModifierKeyState have only MODIFIER_ALTGRAPH or
MODIFIER_CONTROL/MODIFIER_ALT.
Additionally, this patch makes VirtualKey::ShiftState treat "AltGraph" as a
modifier. So, now, VirtualKey needs to convert ShiftState to index value when
it accesses its mShiftStates array. Therefore, this patch adds
VirtualKey::ToIndex() and make each VirtualKey method use it before
accessing mShiftStates.
Note that this patch also fixes bug of WinUtils::SetupKeyModifiersSequence().
The constructor of KeyPair takes 2 keycode values, but the second virtual
keycode can have scancode to distinguish if the key is left or right.
However, WinUtils::SetupKeyModifiersSequence() never sets scancode to
KeyPair. Therefore, it fails to dispatch AltRight key event.
MozReview-Commit-ID: 7ealxJH9KlZ
--HG--
extra : rebase_source : 761bc4416222def020a0731d6ae7940ef074ebe0
Original patch author is Takuro Ashie <ashie@clear-code.com>
Provide ability to create native EGL window and provide it under NS_NATIVE_EGL_WINDOW
to GL code. The native EGL window is owned/managed by mozcontainer.
MozReview-Commit-ID: 4d0Kk6DRSaD
--HG--
extra : rebase_source : e4677ce51fbf918eb1b0257c66ca4b7220174bbb