Most of our keyboard shortcut handling is handled by nsXBLWindowKeyHandler along
with nsXBLPrototypeHandler. With the impending removal of XBL this needs to
change.
This patch moves nsXBLWindowKeyHandler to dom/events/GlobalKeyListener and copies
nsXBLPrototypeHandler to dom/events/KeyEventHandler. Windows, text elements and
XUL <keyset> are changed to use the new copies and anything unnecessary for
those is stripped out.
XBL handler elements still remain using the existing nsXBLPrototypeHandler path.
Some of the code is ripped out there to make it compile. There is probably a
lot more that can be removed but since the whole of XBL is likely gone soon I'm
not sure it is worth cleaning that up much.
Differential Revision: https://phabricator.services.mozilla.com/D42336
--HG--
rename : dom/xbl/nsXBLWindowKeyHandler.cpp => dom/events/GlobalKeyListener.cpp
rename : dom/xbl/nsXBLWindowKeyHandler.h => dom/events/GlobalKeyListener.h
rename : dom/xbl/nsXBLPrototypeHandler.cpp => dom/events/KeyEventHandler.cpp
rename : dom/xbl/nsXBLPrototypeHandler.h => dom/events/KeyEventHandler.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForBrowserCommon.h => dom/events/ShortcutKeyDefinitionsForBrowserCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForEditorCommon.h => dom/events/ShortcutKeyDefinitionsForEditorCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForInputCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForTextAreaCommon.h
rename : dom/xbl/builtin/ShortcutKeys.cpp => dom/events/ShortcutKeys.cpp
rename : dom/xbl/builtin/ShortcutKeys.h => dom/events/ShortcutKeys.h
rename : dom/xbl/builtin/android/ShortcutKeyDefinitions.cpp => dom/events/android/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/android/moz.build
rename : dom/xbl/builtin/emacs/ShortcutKeyDefinitions.cpp => dom/events/emacs/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/emacs/moz.build
rename : dom/xbl/builtin/mac/ShortcutKeyDefinitions.cpp => dom/events/mac/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/mac/moz.build
rename : dom/xbl/builtin/unix/ShortcutKeyDefinitions.cpp => dom/events/unix/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/unix/moz.build
rename : dom/xbl/builtin/win/ShortcutKeyDefinitions.cpp => dom/events/win/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/win/moz.build
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
Most of things will likely be no real change because they ask for the exact frame they want immediately before.
Differential Revision: https://phabricator.services.mozilla.com/D44359
--HG--
extra : moz-landing-system : lando
This was fixed upstream, so we can eventually remove this.
Having the issue number makes it much nicer to figure out when is the right time
to remove it.
Differential Revision: https://phabricator.services.mozilla.com/D44624
--HG--
extra : moz-landing-system : lando
- Allow to create WaylandDMABufSurface with wl_buffer or EGLImage on top of it
- Disable dmabuf modifiers as they slow down the data upload
- Add ability to export/import WaylandDMABufSurface via. file descriptors
Differential Revision: https://phabricator.services.mozilla.com/D43609
--HG--
extra : moz-landing-system : lando
I would like to log `IMEState` and `InputContextAction`in widget. But this
utilities are in `IMEStateManager`, so I would like to move it to widget
by using `mozilla/ToString.h`.
Differential Revision: https://phabricator.services.mozilla.com/D44103
--HG--
extra : moz-landing-system : lando
The test for procinfo doesn't check if the process type is
reasonable. With Fission, this test now asserts, so add a failure
annotation. I'll fix it up for Fission in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D44214
--HG--
extra : moz-landing-system : lando
ProcType gets turned into WebIDLProcType, so I assume the intention is
that they are identical. I changed the definition of WebIDLProcType to
match ProcType, and added a static assert to check that they have the
same number of cases.
I also changed the coercion from a static_cast<> to an explicit switch
statement so that it will degrade more gracefully if, say, the enums
get reordered, or one enum gets a case added and removed at the same
time.
Differential Revision: https://phabricator.services.mozilla.com/D44212
--HG--
extra : moz-landing-system : lando
- Use former ReparentNativeWidgetInternal() code in nsWindow::SetParent().
Also update mToplevelParentWindow for Wayland to hold default toplevel window.
- Make nsWindow::ReparentNativeWidget() to work on toplevel windows only and use only gtk_window_set_transient_for() to reparent
a toplevel window. Also update mToplevelParentWindow for Wayland.
Differential Revision: https://phabricator.services.mozilla.com/D43600
--HG--
extra : moz-landing-system : lando
Chrome flags need to be set both on the `window` and the `browser` object.
Right now we only set them on the `browser` objects and that could lead to
unintended consequences. This patch sets the flags to the `window` accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D43523
--HG--
extra : moz-landing-system : lando
For popup windows with parent we need to get scale factor of the parent
window. Because when the windows are hidden they're not receiving updates
about changing scaling factor. So when moving from normal dpi to
the hidpi monitor the newly opened popup windows will have the same scale
Differential Revision: https://phabricator.services.mozilla.com/D41947
--HG--
extra : moz-landing-system : lando
4eca0f08c43b73dc1dd908fad58bdfd7f6973119 introduced dynamic linking of urlmon
for MinGW as a workaround. Now that MinGW was updated, we can remove that
workaround.
Differential Revision: https://phabricator.services.mozilla.com/D43281
--HG--
extra : moz-landing-system : lando
Recently window resize on Wayland produces flickering/rendering artifacts because
window background is randomly cleared due to actual window size changes.
We recently query widget size and do clear/fullscreen update when the size changes.
To avoid that, get widget size once at WindowSurfaceWayland::Lock() and use it
until next WindowSurfaceWayland::Lock(). Also don't to switch wayland back buffers
until there's really fullscreen update from compositor.
This patch:
- Use mLockedScreenRect to store window size at WindowSurfaceWayland::Lock(). It's used
to detect widget resize, when it happens throw away all cached painting and wait for
full screen update.
- Use mBufferScreenRect to store size of wayland back buffer and pass it
instead of actual widget size we used before this patch. This ensures all our
drawing matches the buffer size.
- Rename aFullScreenUpdate to aCanSwitchBuffer at LockWaylandBuffer() to stress
actual meaning - we can/can't switch back buffers for partial drawing and we need to
wait until recent back buffer is released by compositor.
Differential Revision: https://phabricator.services.mozilla.com/D43263
--HG--
extra : moz-landing-system : lando
Converts dom.w3c_pointer_events.dispatch_by_pointer_messages to a static pref and removes its mirror variable.
Differential Revision: https://phabricator.services.mozilla.com/D43524
--HG--
extra : moz-landing-system : lando
Converts ui.context_menus.after_mouseup varcache pref to a static pref and removes its associated function.
Differential Revision: https://phabricator.services.mozilla.com/D43519
--HG--
extra : moz-landing-system : lando
Converts layout.css.devPixelsPerPx to a static pref. This one was one of the slightly odd ones; some values were expecting an atomic float, so instead of defining a regular type float it is defined in StaticPrefList.yaml as an AtomicFloat. I am assuming this was the intent of the pref value all along.
Differential Revision: https://phabricator.services.mozilla.com/D42396
--HG--
extra : moz-landing-system : lando
Converts android.widget_paints_background to a static pref. From my understanding, this pref only matters on android, and the overridden function in nsIWidget defaults to `false`. Based on that I replaced the entire WidgetPaintsBackground() function with a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D42395
--HG--
extra : moz-landing-system : lando
Converts ui.scrolling.negate_wheel_scroll to a static pref and updates its usages. This one is only enabled on android, so I used the IS_ANDROID value to fill it.
Differential Revision: https://phabricator.services.mozilla.com/D42394
--HG--
extra : moz-landing-system : lando
Converts intl.ime.hack.on_any_apps.fire_key_events_for_composition to a static pref and updates its usages.
Differential Revision: https://phabricator.services.mozilla.com/D42393
--HG--
extra : moz-landing-system : lando
Converts ui.key.generalAccessKey, ui.key.chromeAccess, and ui.key.contentAccess to static prefs. Updates usages.
Differential Revision: https://phabricator.services.mozilla.com/D42392
--HG--
extra : moz-landing-system : lando
Converts dom.keyboardevent.dispatch_during_composition and dom.keyboardevent.keypress.dispatch_non_printable_keys_only_system_group_in_content to static prefs. Removes the dispatch_during_composition entry from mobile.js, since it just redefines the same pref value.
Differential Revision: https://phabricator.services.mozilla.com/D42391
--HG--
extra : moz-landing-system : lando
Converts browser.tabs.remote.desktopBehavior to a static pref. Updates usages.
Differential Revision: https://phabricator.services.mozilla.com/D42390
--HG--
extra : moz-landing-system : lando
I've tried hard to find a solution for the clipped window button problem which
does not involve swizzling but could not find one.
The officially ratified ways of moving the window buttons are:
1. Use an NSToolbar in your window, or
2. Make a custom window with your own buttons.
I don't think having an NSToolbar is an option for us. And making our own window frame
implementation would be hard to get right and can easily behave differently from the
native implementation.
I've also tried asking the window to not render any window buttons on its own; then we
could make our own buttons and place them on top of our view. But if I change the
window's styleMask to be just NSTitledWindowMask, it doesn't only make the buttons
disappear, it also makes the window non-resizable. And if I include NSResizableWindowMask,
the buttons come back (only the zoom button is enabled, the other two are grayed out).
This change also stops overriding _wantsFloatingTitlebar when CoreAnimation is
enabled, which is necessary for the window buttons to render.
Depends on D43341
Differential Revision: https://phabricator.services.mozilla.com/D43361
--HG--
extra : moz-landing-system : lando
This gives us two behaviors for free which we were achieving through manual
overrides:
- The content view is sized to cover the entire window frame.
- The window controls are placed on top of the content view (instead of
underneath it in z-order).
It also forces CoreAnimation layers for the window's entire NSView hierarchy, so
we only use it when the CoreAnimation pref is enabled.
NSFullSizeContentViewWindowMask is only available on 10.10 and up, but we still
support 10.9, so we cannot remove the code with the manual overrides just yet.
This change also requires a change to NonDraggableView in order to preserve
window dragging behavior in the titlebar: When NSFullSizeContentViewWindowMask
is used, the method which assembles the window's draggable region takes a
different path. It treats the titlebar specially, and traverses the NSView
hierarchy twice, once for the titlebar area and once for the rest of the window.
Outside the titlebar, it calls _opaqueRect on every visible NSView, but for the
titlebar area, it calls _opaqueRectForWindowMoveWhenInTitlebar instead.
Overriding _opaqueRectForWindowMoveWhenInTitlebar allows us to achieve the old
dragging behavior.
Differential Revision: https://phabricator.services.mozilla.com/D43341
--HG--
extra : moz-landing-system : lando
This makes them only apply in windows with titlebars, which is the only place
where they're needed. The setContentView override can even cause harm for other
windows, such as sheet windows, because it'll move the content view below a
full-window covering solid grey view provided by the system, in builds that
link against the 10.14 SDK and don't override _wantsFloatingTitlebar.
Differential Revision: https://phabricator.services.mozilla.com/D43340
--HG--
extra : moz-landing-system : lando
