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
It looks like a big patch but it's mostly just moved code, with some duplication:
- Layer creation and destruction moves to LayerManagerComposite and RendererOGL.
- BasicCompositor IOSurface setup code moves to BasicCompositor.cpp.
- OpenGL IOSurface setup code moves to CompositorOGL and RenderCompositorOGL.
The duplication is a bit unfortunate but the LayerManagerComposite code will
diverge from the WebRender code soon.
BeginFrame gets a new argument aNativeLayer. This argument will go away again
over the course of this patch queue. But for now, BeginFrame is the best place
to do the layer setup because it's a very close place to PreRender which is
where that code was previously.
I wasn't able to think of a nice way to give CompositorOGL and BasicCompositor
platform-specific behavior without #ifdefs. So now LayerManagerComposite uses
the "cross-platform" NativeLayer interface, but CompositorOGL and
BasicCompositor use NativeLayerCA because they actually need the IOSurface, and
they do that in #ifdef'd code.
Luckily, NativeLayerCA.h can be included in both .cpp files and in .mm files.
Differential Revision: https://phabricator.services.mozilla.com/D42402
--HG--
extra : moz-landing-system : lando
This lets LayerManagerComposite and RendererOGL set the correct opaque region
on the native layer.
Differential Revision: https://phabricator.services.mozilla.com/D42401
--HG--
extra : moz-landing-system : lando
MANUAL PUSH: Backout and comment change that don't require a review and are somewhat time-critical: the backout fixes breakage in some local build scenarios.
--HG--
extra : rebase_source : 5230000ce88395794c272f0133e09979c70d526d
extra : amend_source : df014e518d27480c5b149acb8acaa0433565d483
The source of the trouble is our setContents override, which makes sure the window's
content view is the bottommost view in the window, and its interaction with a change
in behavior on 10.14, where windows that return YES from _wantsFloatingTitlebar will
contain an additional NSView for the window background. Our setContents override
moves the content view behind that window background view, which covers it with a
solid gray color.
--HG--
extra : amend_source : cd11d5c805de7054c3dfa3a1d5ae0f504f07116d
Bug 1278282 removed Gtk2 support, so MOZ_WIDGET_TOOLKIT is always "gtk3"
for Gtk builds, and never "gtk", which makes the current check never
match.
Differential Revision: https://phabricator.services.mozilla.com/D42761
--HG--
extra : moz-landing-system : lando
Until now, `WinUtils::PreparePathForTelemetry` did not whitelist paths
originating from the Windows system directory. This is unfortunate, as those
paths are not going to contain any PII yet may be useful for troubleshooting.
By adding `%SystemRoot%` to the whitelist, such paths will be included after
substituting the real system directory with the name of the environment
variable.
Finally, we need to lazily build the whitelist in a thread-safe manner.
Whitelist construction has been refactored so that the whitelist is a static
local variable that is atomically constructed.
Differential Revision: https://phabricator.services.mozilla.com/D42916
--HG--
extra : moz-landing-system : lando
This also moves the MaybeScheduleUnsuspendAsyncCATransactions() call to the end
of HandleMainThreadCATransaction() so that we can't get re-suspended from within
WillPaintWindow().
Differential Revision: https://phabricator.services.mozilla.com/D42763
--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
This can be verified by starting Firefox with the environment variables
CA_LAYER_SURFACE=0 CA_COLOR_OPAQUE=1
Transparent parts of the window will be red, and opaque parts will be green.
With this patch, the main browser window will be opaque except for the vibrant
areas, i.e. the tab bar and any open sidebars, which will be transparent.
Full screen video will be opaque.
Differential Revision: https://phabricator.services.mozilla.com/D40555
--HG--
extra : moz-landing-system : lando
ScreenPixels would be a more appropriate unit. But inside BasicCompositor everything
is in the same coordinate space anyway so we're not getting much benefit from the
units. This patch eliminates a lot of .ToUnknown*() calls.
Differential Revision: https://phabricator.services.mozilla.com/D41680
--HG--
extra : moz-landing-system : lando
On Windows, where the DrawTarget is rewrapped in a Cairo/pixman DrawTarget,
this will now cause Cairo/pixman to be used for the clear.
Differential Revision: https://phabricator.services.mozilla.com/D41673
--HG--
extra : moz-landing-system : lando
This should be equivalent to what we had before but clearer.
Before this patch, we would reallocate the back buffer if
- the back buffer was larger than the client size (meaning the window had shrunk) or
- the invalid region didn't fit in the back buffer.
Whenever the window is resized, we have a frame where the invalid region covers
the entire window, and thus size would be equal clientSize in that frame.
So effectively, the back buffer size was always kept in sync with the client size.
Differential Revision: https://phabricator.services.mozilla.com/D41671
--HG--
extra : moz-landing-system : lando
For launching with an external protocol handler on Windows, we validate a uri
before sending it to `ShellExecute`, by converting a string into `PIDL` using
`SHParseDisplayName` and extract a string back from PIDL using
`IShellFolder::GetDisplayNameOf`. The problem was that if a fragment, a
string following a hash mark (#), is always dropped after this validation.
This is caused by the intended design of Windows.
A proposed fix is to use `CreateUri` for validation, which is used behind
`IShellFolder::GetDisplayNameOf`. However, we also keep `SHParseDisplayName`
because there are cases where `CreateUri` succeeds while `SHParseDisplayName`
fails such as a non-existent `file:` uri and we want to keep the same
validation result for those cases.
Adding `CreateUri` broke MinGW build because of our toolkit issue. We use
dynamic linking for MinGW build in the meantime.
This patch adds a new unittest to make sure the new validation logic
behaves the same as the old one except the fragment issue.
Differential Revision: https://phabricator.services.mozilla.com/D42041
--HG--
extra : moz-landing-system : lando
For launching with an external protocol handler on Windows, we validate a uri
before sending it to `ShellExecute`, by converting a string into `PIDL` using
`SHParseDisplayName` and extract a string back from PIDL using
`IShellFolder::GetDisplayNameOf`. The problem was that if a fragment, a
string following a hash mark (#), is always dropped after this validation.
This is caused by the intended design of Windows.
A proposed fix is to use `CreateUri` for validation, which is used behind
`IShellFolder::GetDisplayNameOf`. However, we also keep `SHParseDisplayName`
because there are cases where `CreateUri` succeeds while `SHParseDisplayName`
fails such as a non-existent `file:` uri and we want to keep the same
validation result for those cases.
This patch adds a new unittest to make sure the new validation logic
behaves the same as the old one except the fragment issue.
Differential Revision: https://phabricator.services.mozilla.com/D42041
--HG--
extra : moz-landing-system : lando
updateLayer expects some objects to be non-null which are only initialized when the pref is set.
But in builds that were compiled with the 10.14 SDK, all NSViews are layer-backed by default, so
wantspdateLayer gets called, and returning YES from that unconditionally will cause updateLayer
to be called.
Differential Revision: https://phabricator.services.mozilla.com/D42333
--HG--
extra : amend_source : a7a1f7ecba9418e3bf5464bca90ba655002bc637
Without this, in windows with title bars, such as the bookmark library window,
the title bar and the content would update at different times.
The title bar paint is done as part of a main thread CoreAnimation transaction.
However, by default, we don't get notified of all main thread CA transactions;
our only notification mechanism is the updateLayer handler on the PixelHostingView,
and that handler is only invoked (the layer is only displayed) if the layer has
been marked as needing display. And by default, window focus changes do not mark
random views' backing layers as needing display. Usually, what this means is that
the window will be painted twice: Once in the main thread transaction, and then
another time on the compositor thread once Gecko has noticed a state change and
triggered its own composite in response. (Often, Gecko's compositor-side paint
will actually happen *before* the main thread paint, because the main thread is
often busy with repainting the system menu bar during window focus changes.)
Such non-atomic window repaints look glitchy.
Calling SuspendAsyncCATransactions will result in a call to updateLayer in the
upcoming CoreAnimation transaction and lets us update the entire window in one
atomic paint, and it will avoid updating the window early if the compositor
thread gets ahead of the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D38759
--HG--
extra : moz-landing-system : lando
Window overlay drawing was added as a workaround for the following:
When our NSOpenGLContext covered the entire window, it would cover the titlebar
contents and hide the window buttons and the title string. It would also not
get anti-aliased rounded corner clipping.
In windows that use CoreAnimation layers for the window frame, this is no longer
a problem, because the CoreAnimation layer tree takes care of these effects:
It applies rounded corner clipping to the window content layers, it puts the
window buttons on top, and it also puts the title string on top if it is shown.
So when we're using CoreAnimation, the existing code needs to be deactivated,
otherwise we'd draw those things twice.
Differential Revision: https://phabricator.services.mozilla.com/D38760
--HG--
extra : moz-landing-system : lando
Now CoreAnimation supports all rendering paths.
The BasicCompositor OMTC path is used when hardware acceleration is disabled,
for example in safe mode or when the user manually disabled it.
Differential Revision: https://phabricator.services.mozilla.com/D38758
--HG--
extra : moz-landing-system : lando
This makes windows that render using CompositorOGL or WebRender show content.
Differential Revision: https://phabricator.services.mozilla.com/D40517
--HG--
extra : moz-landing-system : lando
This makes context menus work. Regular windows are still blank at this point.
This introduces a visual regression on 10.9: context menus and panels now no
longer have a shadow. Only 10.10 and above support shadows on transparent windows
that use CoreAnimation; 10.9 is not able to obtain the shadow shape on those
types of windows.
I think this is an acceptable regression to take. We want to use CoreAnimation
for all window types because it simplifies the code (no need to handle two
paths) and because it avoids expensive mode switches if we realize too late
that a window we just opened is supposed to use CoreAnimation.
Differential Revision: https://phabricator.services.mozilla.com/D40516
--HG--
extra : moz-landing-system : lando
This makes mPixelHostingView layer-backed, and that layer will be empty.
This patch also causes all windows (including context menus, tooltips, arrow
panels etc.) to use CoreAnimation layers for the window frame. This is achieved
by calling setWantsLayer:YES on every window's content view.
After this changeset, all windows will still be empty.
Differential Revision: https://phabricator.services.mozilla.com/D38755
--HG--
extra : moz-landing-system : lando
This patch leaves you with empty windows everywhere. We will build the new
rendering paths from the ground up in the upcoming patches.
Differential Revision: https://phabricator.services.mozilla.com/D38754
--HG--
extra : moz-landing-system : lando
Unlike what the old comment in its drawRect method says, this isn't actually
dependent on the NSFullSizeContentViewWindowMask. Any window that uses
CoreAnimation layers for its window frame will apply these effects automatically.
Differential Revision: https://phabricator.services.mozilla.com/D38753
--HG--
extra : moz-landing-system : lando
We always use OMTC when using OpenGL. We also currently always use OpenGL when using OMTC, but that's about to change.
Differential Revision: https://phabricator.services.mozilla.com/D38752
--HG--
extra : moz-landing-system : lando
BasicLayers is main thread drawing. BasicCompositor is compositor-thread drawing.
Differential Revision: https://phabricator.services.mozilla.com/D38749
--HG--
extra : moz-landing-system : lando
Image cache mode can be set by widget.wayland_cache_mode.
- widget.wayland_cache_mode = 0 (or missing):
Cache and clip all drawings, default. It's slowest
but also without any rendered artifacts.
- widget.wayland_cache_mode = 1:
Cache drawing only when back buffer is missing. May produce
some rendering artifacts and flickering when partial screen update
is rendered.
- widget.wayland_cache_mode = 2:
Don't cache anything, draw only when back buffer is available.
Suitable for fullscreen content only like fullscreen video playback and
may work well with dmabuf backend.
Differential Revision: https://phabricator.services.mozilla.com/D43681
This fixes several tests which snapshot remote windows under Fission. It also
changes some other arbitrary tests that don't use remote windows, which I
changed before I gave up on having an always-async API.
Differential Revision: https://phabricator.services.mozilla.com/D41630
--HG--
extra : rebase_source : 6203b7065f7651e6ed4a2695ff2bd92daec70634
This is needed to let WebRender run on ANGLE/WARP because we end up with
the Microsoft vendor.
Differential Revision: https://phabricator.services.mozilla.com/D41853
--HG--
extra : moz-landing-system : lando
Investigation showed that on this platform the texture unit state becomes
corrupted whenever we set the non-identity swizzling (getting garbage from textureSize()).
Given no easy workaround, we disable swizzling for this GPU family on Mac, for now.
Differential Revision: https://phabricator.services.mozilla.com/D41274
--HG--
extra : moz-landing-system : lando
Under Wayland the GTK does not send the correct window state event change
when the window is iconified. We need to add a workaround for that to avoid
unresponsive UI after restoring the window.
Differential Revision: https://phabricator.services.mozilla.com/D41219
--HG--
extra : moz-landing-system : lando
Converts mozilla.widget.disable-native-theme varcache pref to a static pref and updates uses of its associated global variable with the pref. This also renames the pref to widget.disable-native-theme to group with other widget prefs.
Differential Revision: https://phabricator.services.mozilla.com/D40721
--HG--
extra : moz-landing-system : lando
The early return for non-popup windows was to workaround
https://bugzilla.mozilla.org/show_bug.cgi?id=1344839 which involved problems
with CleanLayerManagerRecursive(). In cases where layer manager configuration
does not change, there is no need to clean the layer manager and so no need to
return early.
Differential Revision: https://phabricator.services.mozilla.com/D40145
--HG--
extra : moz-landing-system : lando
These are now being hit because of the removal of the HTML frames
customizations to the print dialog.
I've removed the defines for these, because I don't think there is any point
trying to guess what their uses are.
I've also made it 32-bit only, because we only see them on 32-bit Windows 7.
In fact only 32-bit Firefox on 64-bit Windows 7 I believe.
Differential Revision: https://phabricator.services.mozilla.com/D40433
--HG--
extra : moz-landing-system : lando
If the popup is a regular menu but GetParentMenuWidget() returns
nullptr, it's connected non-menu parent (bookmark toolbar for instance).
In this case use a parent given at nsWindow::Create() and don't attach it
to latest active popup as it has a real parent.
Depends on D39347
Differential Revision: https://phabricator.services.mozilla.com/D39348
--HG--
extra : moz-landing-system : lando
- gtk_window_get_transient_for() fails to return correct toplevel window as the toplevel window changes
when popup is moved in popup hierarchy. So store the toplevel given at nsWindow::Create() and
use it instead.
- Remove some redundat NS_WARNING() from wayland code
- Attach "moved-to-rect" signal handler to GdkWindow only once a update
NativeMoveResizeWaylandPopupCallback() loging.
- Add more logging to Wayland popup related code.
Differential Revision: https://phabricator.services.mozilla.com/D39347
--HG--
extra : moz-landing-system : lando
If the popup is a regular menu but GetParentMenuWidget() returns
nullptr, it's connected non-menu parent (bookmark toolbar for instance).
In this case use a parent given at nsWindow::Create() and don't attach it
to latest active popup as it has a real parent.
Depends on D39347
Differential Revision: https://phabricator.services.mozilla.com/D39348
--HG--
extra : moz-landing-system : lando
- gtk_window_get_transient_for() fails to return correct toplevel window as the toplevel window changes
when popup is moved in popup hierarchy. So store the toplevel given at nsWindow::Create() and
use it instead.
- Remove some redundat NS_WARNING() from wayland code
- Attach "moved-to-rect" signal handler to GdkWindow only once a update
NativeMoveResizeWaylandPopupCallback() loging.
- Add more logging to Wayland popup related code.
Differential Revision: https://phabricator.services.mozilla.com/D39347
--HG--
extra : moz-landing-system : lando
When the popup is without parent it mess up with the Wayland popup hierarchy.
Then any other popup cannot be shown, for example when webrtc ui
shows up the user is unable to allow sharing screen during that.
Differential Revision: https://phabricator.services.mozilla.com/D38507
--HG--
extra : moz-landing-system : lando
`IShellWindows::FindWindowSW` may return the dreaded `S_FALSE`, so we need to
ensure that we're handling that.
I checked the remaining functions called by this code and none of the others
do this; this is the only call site that requires the check.
I'm not sure why we're seeing this error code. I added an explicit cast to
ensure that `CSIDL_DESKTOP` is being interpreted as an `int`, though I doubt
that this actually makes any difference.
Differential Revision: https://phabricator.services.mozilla.com/D39799
--HG--
extra : moz-landing-system : lando
Use addGlobalMonitorForEventsMatchingMask instead of CGEventTapCreate to monitor for mouse clicks outside of the application while context menus are displayed.
Using addGlobalMonitorForEventsMatchingMask prevents the display of the privacy "Keystroke Receiving" dialog when listening for mouse clicks.
Differential Revision: https://phabricator.services.mozilla.com/D39973
--HG--
extra : moz-landing-system : lando
When ClientLayerManager::Initialize() fails, we also need to clear LayerManager.
Differential Revision: https://phabricator.services.mozilla.com/D39817
--HG--
extra : moz-landing-system : lando
They're infallible in practice and always `NS_OK`. (This stems from
`AddVarCacheNoAssignment()` always returning `NS_OK`.)
As a result, the commit removes lots of unnecessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D39804
--HG--
extra : moz-landing-system : lando
Some initialization handlings of ClientLayerManager exists in nsBaseWidget::CreateCompositor(). It is not good. Move them to ClientLayerManager::Initialize().
Differential Revision: https://phabricator.services.mozilla.com/D39476
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This is to ensure that multiple completions cannot be attempted on the same `GeckoResult`, resulting in crashes.
Differential Revision: https://phabricator.services.mozilla.com/D36929
--HG--
extra : moz-landing-system : lando
This is caused by a race condition when the compositor is detached. Because the actual detachment happens in a new thread, `detach` can complete and release the lock on `mLayerViewSupport`, and `RecvScreenPixels` can obtain the lock, before `mLayerViewSupport` is properly cleaned up. We therefore check to ensure that `lvs` is not null before calling a method on it.
Differential Revision: https://phabricator.services.mozilla.com/D36928
--HG--
extra : moz-landing-system : lando
For the URI handling case, we still want to parse the URI to look for any
malformation. OTOH, IShellDispatch2::ShellExecute does not accept PIDLs as
arguments, we we need an overload that converts the absolute PIDL back to a
path for the purposes of passing on to that interface.
Differential Revision: https://phabricator.services.mozilla.com/D38944
--HG--
extra : moz-landing-system : lando
