Adds nsIOSPermissionRequest::GetScreenCapturePermissionState() to allow front-end code to check if Firefox has already been granted permission to record the screen.
Differential Revision: https://phabricator.services.mozilla.com/D46093
--HG--
extra : moz-landing-system : lando
Adds a ServiceWorkerDelegate to GeckoRuntime that allows GeckoView applications
to handle ServiceWorkerClient.openWindow() requests.
Differential Revision: https://phabricator.services.mozilla.com/D45572
--HG--
extra : moz-landing-system : lando
This is regression by bug 1530649.
After landing bug 1530649, we try to scan end point of replacement text. But
in this bug's situation, afterRun becomes same as current ws run by landing
bug 1530649. To get white space type of next of replacement end, we have to
scan around end point again.
Differential Revision: https://phabricator.services.mozilla.com/D45947
--HG--
extra : moz-landing-system : lando
- Don't store whole buffer update information at mWholeWindowBufferDamage but use damage region instead.
- Check and remove overlapped images when they are stored at image cache.
- Remove CanDrawToWaylandBufferDirectly() as it's not very useful.
This commit depends on Bug 1580152 which needs to land first.
Differential Revision: https://phabricator.services.mozilla.com/D46140
--HG--
extra : moz-landing-system : lando
- Recently we're missing some drawings as we disabled flushing cached images in frame callback. Let's enable it again and make sure we don't flush the drawings between Lock()/Commit() compositor calls which is controlled by mBufferCommitAllowed.
- When we draw directly to wl_buffer, flush all cached drawings we have or clear them if there's fullscreen update. It prevents potential rendering of cached images over unrelevant buffer content.
- Flush cached images when wl_buffer is detached by wayland compositor. It allows to paint delayed drawings and ensures they won't stay in the queue infinitely.
- Use mBufferPendingCommit to indicate that the WaylandBuffer contains updates from gecko which has not been submitted to wayland compositor yet. Allows delated commit handlers (frame callback, delayed commit and when wl_buffer is detached) to send WaylandBuffer content to wayland compositor.
- Record time of last finished commit to mLastCommitTime and throws warning when wayland compositor does not release wl_buffer in 200ms.
- Use wl_display_sync() to synchronize wl_display events. Wait for events from wl_display until all pending events are processed before we start drawing at WindowSurfaceWayland::Lock(). There may wl_buffer release event waiting which releases wl_buffer for rendering.
- Don't use XMost()/YMost() to get drawing area size.
- Remove mDisplayThreadMessageLoop as it's no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D45661
--HG--
extra : moz-landing-system : lando
The menuitem custom element inserts nodes when rendered. These nodes are
not related to the structure of the menu, but were causing nsMenuItemX
to mark the menu as needing a rebuild. The rebuild would remove all items
from the menu which caused the removal of the special menu items "Start
Dictation" and "Emoji and Symbols" that are automatically added by MacOS.
Differential Revision: https://phabricator.services.mozilla.com/D45420
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
The parent process usually starts a native drag session during the processing
of a Gecko mouse move event while the mouse is down. Usually, these Gecko mouse
move events are processed synchronously during -[ChildView mouseDragged:]. But
in some cases, the Gecko mouse move event can be a synthetic mouse move event
that was generated in response to a reflow. Those get processed during refresh
driver ticks, which run at a time that's completely unrelated to when
mouseDragged is invoked.
So the widget should just assume that drags can be started at any time between
mouseDown and mouseUp.
Differential Revision: https://phabricator.services.mozilla.com/D36151
--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/D45649
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Under Wayland where there's a strict popup window hierarchy, using toplevel window
for the submenus in popupnotification cause the popupnotification to hide
when opening them and this breaks user to Allow/Don't allow the action.
We have to use last opened popup window as a parent for these submenus.
Differential Revision: https://phabricator.services.mozilla.com/D45343
--HG--
extra : moz-landing-system : lando
Also causes removing a pref to take effect immediately, and prevents
losing all color pref overrides when the theme changes.
Differential Revision: https://phabricator.services.mozilla.com/D44416
--HG--
extra : moz-landing-system : lando
- When widget.wayland_cache_mode=1 use direct rendering to wl_buffer only when there isn't any
cached rendering pending and we're updating one big piece of screen (video playback/scrolling etc..)
- Disable frame callback commits between WindowSurfaceWayland::Lock and WindowSurfaceWayland::Commit
as the buffer can be updated by gecko compositor
Differential Revision: https://phabricator.services.mozilla.com/D45184
--HG--
extra : moz-landing-system : lando
Recently direct wl_buffer rendering is kept enabled until we have wl_buffer available which
produces rendering artifacts when screen damage rects overlaps.
Let's enable/disable it explicitly at every rendering cycle start to avoid
screen flickering.
Depends on D45166
Differential Revision: https://phabricator.services.mozilla.com/D45167
--HG--
extra : moz-landing-system : lando
Use wl_surface_damage_buffer() to propagate wl_buffer damage to avoid rounding errors and
rendering artifacts for HiDPI wl_buffers.
Depends on D45165
Differential Revision: https://phabricator.services.mozilla.com/D45166
--HG--
extra : moz-landing-system : lando
`WindowsErrorResult` is a class to hold either a value or a Windows error
code based on the `Result` template. We also have `LauncherResult` for the
same purpose, which was introduced as a part of the launcher process feature
afterward. The difference is `LauncherResult` holds a filename and line
number along with an error code.
This patch integrates LauncherResult.h into WinHeaderOnlyUtils.h so that we
can use `LauncherResult` more broadly.
Differential Revision: https://phabricator.services.mozilla.com/D44512
--HG--
extra : moz-landing-system : lando
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
Move lock of window inside thread in `LayerViewSupport::OnDetach` and pop the `GeckoResult` from list of waiting results while we still have the initiallock in `LayerViewSupport::RecvScreenPixels`.
This passes try, but then so did the last patch.
Differential Revision: https://phabricator.services.mozilla.com/D44800
--HG--
extra : moz-landing-system : lando
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
