This restores behavior from before my patch, and makes it so that it's
easier to see which color pair ends up getting used.
Differential Revision: https://phabricator.services.mozilla.com/D157271
Prior to this commit the `ToastNotification`'s observer registration doesn't work due to `ToastNotification` not implementing `nsIWeakReference` while attempting to register itself as an observer as a weak reference.
Differential Revision: https://phabricator.services.mozilla.com/D155764
Non-MSIX notifications are not removed when Firefox is uninstalled. To handled this we've added a new `uninstall` background task and extended `nsIWindowsAlertService` to deregister notifications on uninstall.
Differential Revision: https://phabricator.services.mozilla.com/D156625
Non-MSIX notifications are not removed when Firefox is uninstalled. To handled this we've added a new `uninstall` background task and extended `nsIWindowsAlertService` to deregister notifications on uninstall.
Differential Revision: https://phabricator.services.mozilla.com/D156625
The immediate effect is to make any image larger and more prominent.
This might not be the right option for regular DOM notifications,
which support only `icon` (and not `image`) in Firefox at this time,
but we can adjust (perhaps limiting the generic template to privileged
alerts) as we need in the future.
Differential Revision: https://phabricator.services.mozilla.com/D156873
On Windows, when an alert is privileged and `name` is non-empty, round
trip its `name` (as `privilegedName`) through the Windows notification
mechanism, and provide it to the "relaunch" callback.
Differential Revision: https://phabricator.services.mozilla.com/D156636
I moved the following variables to their method of use:
- sSwitchKeyboardLayout, sCanQuit to nsWindow::ProcessMessageInternal;
- sLastMousePoint, sLastMouseDownTime, sLastClickCount, sLastMouseButton to nsWindow::DispatchMouseEvent;
- sFirstTopLevelWindowCreated to nsWindow::Create;
- sHasBogusPopupsDropShadowOnMultiMonitor to nsWindow::HasBogusPopupsDropShadowOnMultiMonitor;
- gIsSleepMode (now sWasSleepMode) to nsWindow::PostSleepWakeNotification.
I also removed one dead variable called sNeedsToInitMouseWheelSettings, as well as sHaveInitializedPrefs which was not required anymore.
Two variables mentioned in the bug had already been moved out of the nsWindow namespace as part of other changesets:
- sDropShadowEnabled, now replaced by local variables shouldUseDropShadow and sShadowEnabled of nsWindow::Show in https://hg.mozilla.org/integration/autoland/rev/18a7f69d5ce4 ;
- sCustomHCursor, now replaced by local variables sCurrentHCursor and sCurrentHCursorIsCustom of nsWindow::SetCursor in https://hg.mozilla.org/integration/autoland/rev/dd95f1e386f1 .
Differential Revision: https://phabricator.services.mozilla.com/D156539
We'll be defaulting Felt Privacy features to enabled, and allowing them to be disabled by Nimbus (primarily for a holdback study).
Differential Revision: https://phabricator.services.mozilla.com/D153275
Right now we look for first parent only at nsWindow::WaylandGetParentPosition() and that's wrong.
WaylandGetParentPosition() is expected to return popup position in root coordinates regardless of popup parent nembers.
In this patch we calc popup position according to whole popup chain.
Differential Revision: https://phabricator.services.mozilla.com/D156673
When we open a popup window (tooltip for instance) on top of GDK_WINDOW_TYPE_HINT_UTILITY popup, Mutter compositor sends bogus
leave/enter events to the GDK_WINDOW_TYPE_HINT_UTILITY popup (https://gitlab.gnome.org/GNOME/gtk/-/issues/5089).
That leads to immediate tooltip close. As a workaround ignore these
bogus events.
We need to check two affected window types:
- toplevel window with at least two child popups where the first one is
GDK_WINDOW_TYPE_HINT_UTILITY.
- popup GDK_WINDOW_TYPE_HINT_UTILITY with a child popup.
We ignore two bogus leave/enter sequences which are fired by mutter together:
1. Leave (popup) -> Enter (toplevel)
2. Leave (toplevel) -> Enter (popup)
Differential Revision: https://phabricator.services.mozilla.com/D156301
We don't need to hide/show GDK_WINDOW_TYPE_HINT_UTILITY popup type to change it's position.
Hide it only if we need to set correct popup type as such change is done in map event.
Differential Revision: https://phabricator.services.mozilla.com/D156305
When the notification server callback is executed by the Windows
notification system, it invokes Firefox with additional command line
parameters, most importantly the Windows-specific notification
"Windows tag".
If no appropriate Firefox is running, the command line will be
processed, the provided Windows tag will be inspected (and seen to not
be registered with this running Firefox instance) and a "launch URL"
stored as part of the Windows notification itself opened (if one is
provided).
If an appropriate Firefox is running, the remoting protocol will
forward this command line to the running instance. If the instance
recognizes the provided `--notification-windowsTag`, the command line
will be ignored. When the notification server exits, Windows will
fallback to the Windows 8.1 style notification callbacks registered
for this Windows tag and the existing (non notification server)
behaviour will occur.
In fact, the server therefore waits for a Windows tag-specific system
event to be signalled by the invoked Firefox (or a sibling process).
If we were to return `S_OK` from the notification server immediately,
and a running Firefox process would handle the notification via
Windows 8.1-style notification callbacks, then Windows would fall back
to those callbacks. The invoked callbacks unregister themselves upon
completion, often before the launched Firefox has an opportunity to
process the command line. By waiting for this system event, we allow
the invoked Firefox to process the command line while its own
notification callbacks are registered and therefore recognize that its
callbacks will handle the notification.
Differential Revision: https://phabricator.services.mozilla.com/D154468
In background task mode:
1. Re-launch Firefox into the default browsing profile, not the
(possibly ephemeral) background task profile.
2. Don't show the in-product notification settings, which won't apply
to the relevant Firefox profile.
Differential Revision: https://phabricator.services.mozilla.com/D155908
Use the existing mName field of alert which includes the host port and tag (or uuid) for Windows notification tag.
When a notification originates from the browser chrome, generate an identify on the fly as before.
The tag is hashed in order to fit the 16 character limit for tags. Note the limit was bumped to 64 in Windows 10 Creators Update.
Differential Revision: https://phabricator.services.mozilla.com/D155140
When the notification server callback is executed by the Windows
notification system, it invokes Firefox with additional command line
parameters, most importantly the Windows-specific notification
"Windows tag".
If no appropriate Firefox is running, the command line will be
processed, the provided Windows tag will be inspected (and seen to not
be registered with this running Firefox instance) and a "launch URL"
stored as part of the Windows notification itself opened (if one is
provided).
If an appropriate Firefox is running, the remoting protocol will
forward this command line to the running instance. If the instance
recognizes the provided `--notification-windowsTag`, the command line
will be ignored. When the notification server exits, Windows will
fallback to the Windows 8.1 style notification callbacks registered
for this Windows tag and the existing (non notification server)
behaviour will occur.
In fact, the server therefore waits for a Windows tag-specific system
event to be signalled by the invoked Firefox (or a sibling process).
If we were to return `S_OK` from the notification server immediately,
and a running Firefox process would handle the notification via
Windows 8.1-style notification callbacks, then Windows would fall back
to those callbacks. The invoked callbacks unregister themselves upon
completion, often before the launched Firefox has an opportunity to
process the command line. By waiting for this system event, we allow
the invoked Firefox to process the command line while its own
notification callbacks are registered and therefore recognize that its
callbacks will handle the notification.
Differential Revision: https://phabricator.services.mozilla.com/D154468
In background task mode:
1. Re-launch Firefox into the default browsing profile, not the
(possibly ephemeral) background task profile.
2. Don't show the in-product notification settings, which won't apply
to the relevant Firefox profile.
Differential Revision: https://phabricator.services.mozilla.com/D155908
Use the existing mName field of alert which includes the host port and tag (or uuid) for Windows notification tag.
When a notification originates from the browser chrome, generate an identify on the fly as before.
The tag is hashed in order to fit the 16 character limit for tags. Note the limit was bumped to 64 in Windows 10 Creators Update.
Differential Revision: https://phabricator.services.mozilla.com/D155140
`launchURL` captures the URL that triggered the alert, if it comes
from a DOM notification. If Firefox is launched when not already
running to handle an alert, it will navigate to this URL.
This URL can be set, and chrome privileged alerts can use this to
launch Firefox to a specific URL when it is launched. Toast
notifications popped by background tasks will use this to re-engage
Firefox users to a campaign-specific URL.
This functionality will be tested in the Windows-specific tests
accompanying Bug 1781929.
Differential Revision: https://phabricator.services.mozilla.com/D155907
This allows Windows native notification action buttons to access the
built-in "dismiss" and "snooze" support without requiring a Firefox
invocation.
Differential Revision: https://phabricator.services.mozilla.com/D155906
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
After the previous changes there was only one consumer left of the Shmem
version of GetSurfaceData, which could easily be changed to use BigBuffer,
removing the need for that overload.
After that consumer is removed, the interface was also simplified as the
generic logic in the implementation was no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D151854
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
We'll be defaulting Felt Privacy features to enabled, and allowing them to be disabled by Nimbus (primarily for a holdback study).
Differential Revision: https://phabricator.services.mozilla.com/D153275
Unfortunately this test doesn't run as expected on our CI since macs on our CI
are running normal DPI mode.
I tested this test works properly on my macbook, it fails without the fix in the
previous commit and it passes with the fix.
Differential Revision: https://phabricator.services.mozilla.com/D153688
Also moved from `typedef` to `using _ =` syntax to match new templated import of `ComPtr` in ToastNotificationHandler.h.
Depends on D155525
Differential Revision: https://phabricator.services.mozilla.com/D155526
We will be defaulting Felt Privacy features to enabled, and allowing them to be disabled by Nimbus (primarily for a holdback study).
Differential Revision: https://phabricator.services.mozilla.com/D153275
After the previous changes there was only one consumer left of the Shmem
version of GetSurfaceData, which could easily be changed to use BigBuffer,
removing the need for that overload.
After that consumer is removed, the interface was also simplified as the
generic logic in the implementation was no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D151854
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
In CI, we fail the glxtest which disables all gfx features, including
the backdrop filter feature. We can just enable it on Linux. A follow up
series of patches will reform the blocklist to prevent these footguns in
the future in the next nightly cycle.
Differential Revision: https://phabricator.services.mozilla.com/D155041
The "preferred" one is the behavior we have for chrome docs, where we
fall back always to the document's preferred color-scheme rather than
falling back to light.
We'll use this in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D154923
Backdrop filter crashes newer Intel drivers on Windows. This patch adds
support to the blocklist infrastructure for backdrop filter, and hooks
this up with the CSS property table.
Differential Revision: https://phabricator.services.mozilla.com/D154950
On Android we have until now determined the compositor widget's size
by querying the values from the ANativeWindow. However, since bug
1780093 landed we can now switch between which Surface we are
rendering in to, and as a result we appear to be using the wrong size
some of the time.
This patch is a speculative attempt to fix this, by using the size
passed to ResumeAndResize() (which itself comes from the Surface's
surfaceChanged() callback) rather than querying the window.
Differential Revision: https://phabricator.services.mozilla.com/D154909
Remove outdated check for move-to-rect. It's redundant and it's implemented in more complex way by nsWindow::WaylandPopupCheckAndGetAnchor() now.
Differential Revision: https://phabricator.services.mozilla.com/D154882
Backdrop filter crashes newer Intel drivers on Windows. This patch adds
support to the blocklist infrastructure for backdrop filter, and hooks
this up with the CSS property table.
Differential Revision: https://phabricator.services.mozilla.com/D154950
When entering fullscreen and saving the original position of a window,
also save the original position of its screen.
When leaving fullscreen, keep the window on the same screen. Restore its
_screen-relative_ position, rather than its absolute position.
Differential Revision: https://phabricator.services.mozilla.com/D153410
`HideWindowChrome(false)` may change the reported window size on Mac:
the OS menu bar appears at the top of the screen, and this will cause the
window to shrink if it was fullscreen.
This isn't a problem yet, since we don't check the window dimensions
when exiting fullscreen... but the following commit will do exactly
that. Delay calling `HideWindowChrome` until the last possible minute --
but make sure that it _does_ get called.
Since HideWindowChrome(true) does not presently change the window size
(see bug 498835), no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D154469
Use desktop pixels everywhere:
- Store the old window position as a `DesktopRect`.
- Since `GetRectDisplayPix` is infallible, use the convenience getter
that hands us a `DesktopIntRect`.
- Add a helper function that wraps `Resize()` and takes any `Rect`
which uses `DesktopPixel`s.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153409
A window is fullscreenable iff it's a desktop window (that is, a
positional child of the desktop rather than of another window) -- and
desktop windows are the windows which use desktop-pixel units in
Resize().
Code coverage confirms that the branch when `BoundsUseDesktopPixels()`
returns `false` is never taken in tests.
Under the (hopefully justified) assumption that it's never taken at all,
no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153408
This code path gets executed by existing tests, and I don't believe
there is a way to execute this behavior using our CI, since it's a macOS
version check.
Differential Revision: https://phabricator.services.mozilla.com/D154172
This allows us to correctly draw items with mismatched color-scheme
on GTK.
This is a reasonably simple fix. A more elaborate fix could be not using
appearance to draw menuitems on Linux at all, just like we don't use it
to draw menupopups anymore. But in practice it's a bit harder because we
use it also to draw menubar items (which probably should be its own
appearance type instead). I can look into that, but this seems
reasonable for now.
Differential Revision: https://phabricator.services.mozilla.com/D154680
With this patch moz_container_wayland_surface_lock() always locks MozContainer and needs to be paired with moz_container_wayland_surface_unlock() even if it fails and returns nullptr.
Split moz_container_wayland_add_initial_draw_callback() to two new functions:
- moz_container_wayland_add_initial_draw_callback_locked() is called on locked container and only adds draw callback. It asserts when MozContainer is already to draw as we don't expect it.
- moz_container_wayland_add_or_fire_initial_draw_callback() is called on unlocked container as it has it's own lock. It behaves as original moz_container_wayland_add_initial_draw_callback(), i.e. stores draw callback when MosContainer is not visible and fires draw callback when we're ready to draw.
- implement RAII class MozContainerSurfaceLock and use it to lock moz_contatier and get wl_surface of it.
Differential Revision: https://phabricator.services.mozilla.com/D152276
This lets users e.g. print-to-scale where it matters.
Custom margins are still clamped to unwriteable margins, even when all zeroes,
to avoid impacting user-specified & persisted margins.
Differential Revision: https://phabricator.services.mozilla.com/D152900
With this patch moz_container_wayland_surface_lock() always locks MozContainer and needs to be paired with moz_container_wayland_surface_unlock() even if it fails and returns nullptr.
Split moz_container_wayland_add_initial_draw_callback() to two new functions:
- moz_container_wayland_add_initial_draw_callback_locked() is called on locked container and only adds draw callback. It asserts when MozContainer is already to draw as we don't expect it.
- moz_container_wayland_add_or_fire_initial_draw_callback() is called on unlocked container as it has it's own lock. It behaves as original moz_container_wayland_add_initial_draw_callback(), i.e. stores draw callback when MosContainer is not visible and fires draw callback when we're ready to draw.
- implement RAII class MozContainerSurfaceLock and use it to lock moz_contatier and get wl_surface of it.
Differential Revision: https://phabricator.services.mozilla.com/D152276
Due to different D&D handling on X11 and Wayland we should pass only GDK_ACTION_MOVE to gdk_drag_status().
Different D&D operation passed to gdk_drag_status() is returned back by gdk_drag_context_get_selected_action() so
gdk_drag_context_get_selected_action returns value set by gdk_drag_status() and not D&D modifiers set by CTRL/SHIFT
Also pass correct time to gdk_drag_status().
Depends on D154417
Differential Revision: https://phabricator.services.mozilla.com/D154418
As we handle D&D in time now we can remove the D&D workaround.
It was used to enable D&D until D&D move handler sends reply to system but also enables D&D where should be disabled (like History menu).
Depends on D154416
Differential Revision: https://phabricator.services.mozilla.com/D154417
This is an update to Bug 1730203. We need to answer to D&D inside of D&D move handler due to specific Gtk architecture.
In fix for Bug 1730203 we send the reply but we failed to update D&D status so the reply may be outdated.
In this patch we:
- Set correct D&D state and send reply to D&D motion event
- Move above code to nsDragService (nsDragService::Schedule()) so UpdateDragAction()/ReplyToDragMotion() can be private again.
- Update UpdateDragAction()/ReplyToDragMotion() to use correct GdkDragContext.
- At UpdateDragAction() call gdk_drag_context_get_selected_action() for valid GdkDragContext only.
Depends on D154415
Differential Revision: https://phabricator.services.mozilla.com/D154416
D&D uses nested evenet loops to get data from system. Let's track how deep are they nested for diagnostic purpose.
Depends on D154413
Differential Revision: https://phabricator.services.mozilla.com/D154414
When turning on fission, OOP child frame doesn't receive touch events such as
`touchstart`.
When dispatching touch event from GeckoView side, some informations such as
`mLayersId` are missing since copy constructor of `MultiTouchInput` doesn't
copy all information.
Since the structure of Input data has a lot of members, we should use
`std::move` instead of copy constructor of `InputData`. It can avoid
unnecessary copy.
Differential Revision: https://phabricator.services.mozilla.com/D154242
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
dom/ and dom/webidl/ : Default these files back to DOM: Core & HTML
PluginChild.jsm: Apparently this is only still used for GMP things.
browser/base/content/ : The remaining tests are mostly EME related, so I switched it over to that.
widget/tests/ : No plugin files remain, so I removed the rule.
Differential Revision: https://phabricator.services.mozilla.com/D154537
clang trunk doesn't like it being defined as a enum GdkEventMask,
because it doesn't fit in the value, but OTOH, it's only used in
kEvents, which is a gint.
Differential Revision: https://phabricator.services.mozilla.com/D154357
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
We implement SendNativeTouchpadPan/SynthesizeNativeTouchpadPan (like Windows does for this test).
I tried to use the existing functions SendNativeMouseScrollEvent/SynthesizeNativeMouseScrollEvent which are implemented on Linux and which are what we use for mac on this test, but it's already used for other stuff and it would be very clunky to overload it to make it work for this too.
I didn't see any way to "tag" the gdk events with more info, so making the observer notifier work was clunky. Similarly for getting the phase start/update/end work.
Differential Revision: https://phabricator.services.mozilla.com/D154386
This still doesn't fire on print settings changes, so it uses the
default page size. Which is probably better than nothing, but...
To make viewport-size media-query listeners work more generally for
printed documents, we would need to re-clone the top document
unconditionally for all print settings changes, which needs front-end
work at least, and is dubious if the page changes dynamically.
Differential Revision: https://phabricator.services.mozilla.com/D150499
We have allowed it in nightly for quite a while now and of all drivers
capable of GL(ES) >= 3.0 all either have already their own rules, have
recently be tested (freedreno >= 22.2/panfrost) or are are still
experimental/niche.
So lets finally draw a line from where on rendering regressions will
be driver issues and not our business.
The choosen Mesa version is the upcoming one, containing some fixes
for freedreno. As many distros for ARM devices update their drivers
rather conservatively, the effect of this will only slowly take
effect and even in case of major issues on some drivers (maybe v3d?)
likely allow us to add block rules before hitting many users.
Differential Revision: https://phabricator.services.mozilla.com/D154134
Move popup window move-to-rect config (anchor canculation, check if we need it and can use it) to a new method WaylandPopupCheckAndGetAnchor().
Depends on D153860
Differential Revision: https://phabricator.services.mozilla.com/D154012
Move-to-rect fails to position and show a popup when the popup anchor is outside of its parent window area.
For instance we can't use a rectangle of 10x10 pixels located at -20, -20 as an anchor as it leads to invisible popup window.
But that scenario can happen so we need to use plain move in such case which works and places the popup to -20, -20 coordinates.
Differential Revision: https://phabricator.services.mozilla.com/D153860
- In order to get tooltip position we need to use gtk_window_get_position() as it cover case when GdkWindow is not placed yet.
- Use both gdk_window_move()/gdk_window_move() to reset widget position as a workaround for https://gitlab.gnome.org/GNOME/gtk/-/issues/4071.
- Apply the workaround to tooltips only as it affects only temporary windows.
Differential Revision: https://phabricator.services.mozilla.com/D153859
As popups and Firefox main window can share refresh drivers we need to remove blocked compositing requests of hidden windows to make sure
we're not blocking other windows.
Implement moz_container_wayland_clear_waiting_to_show_flag() to clear MozContainer::waiting_to_show flag.
Depends on D154005
Differential Revision: https://phabricator.services.mozilla.com/D154006
Make RevokeTransactionIdAllocator() call part of nsBaseWidget::DestroyCompositor() so we don't need to do extra call.
Depends on D154004
Differential Revision: https://phabricator.services.mozilla.com/D154005
When entering fullscreen and saving the original position of a window,
also save the original position of its screen.
When leaving fullscreen, keep the window on the same screen. Restore its
_screen-relative_ position, rather than its absolute position.
Differential Revision: https://phabricator.services.mozilla.com/D153410
Use desktop pixels everywhere:
- Store the old window position as a `DesktopRect`.
- Since `GetRectDisplayPix` is infallible, use the convenience getter
that hands us a `DesktopIntRect`.
- Add a helper function that wraps `Resize()` and takes any `Rect`
which uses `DesktopPixel`s.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153409
A window is fullscreenable iff it's a desktop window (that is, a
positional child of the desktop rather than of another window) -- and
desktop windows are the windows which use desktop-pixel units in
Resize().
Code coverage confirms that the branch when `BoundsUseDesktopPixels()`
returns `false` is never taken in tests.
Under the (hopefully justified) assumption that it's never taken at all,
no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153408
`increaseFontSize`, `decreaseFontSize`, `gethtml`, `heading` and `readonly`
commands were disabled for a year in all channels, but no regression reports
have been filed. Therefore, we can delete the commands and the telemetry
probes.
Note that `cmd_getContents` command which is the internal command of `gethtml`
is not used in comm-central too. Therefore, this patch deletes the command
handler, `nsClipboardGetContentsCommand`, and `Command::GetHTML` too.
Differential Revision: https://phabricator.services.mozilla.com/D153720
In this patch we:
- Implement ResumeCompositorImpl() to unify compositor resume by ResumeCompositorFlickering() and ConfigureCompositor() as the code is almost identical.
- Allow COMPOSITOR_PAUSED_FLICKERING state in ConfigureCompositor() callback - in such case postpone compositor resume to ResumeCompositorFlickering().
Depends on D153573
Differential Revision: https://phabricator.services.mozilla.com/D153574
GeckoView dispatch keyboard event to child process directly and it doesn't
support non-e10s mode. But since about:config will run on chrome process,
GeckoView will dispatch it to parent process.
By bug 1430241, we don't use native key binding when dispatching key event on
parent process. But we forget it for process key event. So even if process key,
we shouldn't use native key binding.
Differential Revision: https://phabricator.services.mozilla.com/D153416
This matches what Linux and macOS do, and that allows the fix for bug 1782623
to work on Windows for unstyled selects.
This also simplifies the CSS (though it adds a new system color which is a bit
more annoying). I filed https://github.com/w3c/csswg-drafts/issues/7561 to
propose adding a more generic way to do this in the future (not just for
Firefox).
Differential Revision: https://phabricator.services.mozilla.com/D153549
Both Chrome and Edge on Windows also move the swipe-to-nav arrow icon, the
distance of move seems to be a fixed value, it doesn't depend on the browser
window size. So we also use a fixed value, 100px here.
Chrome on Mac also moves the icon, but in a slightly different way. The icon is
a semicircle shape, it never leaves the edge of the browser window even if it's
moving during swipe gestures. So we introduce a new preference named
"browser.swipe.navigation-icon-move-distance" to implement platform dependent
swipe-to-nav icon behaviors. As of now the value on platforms other than Windows
is zero so that the icon never moves on the platforms.
Depends on D152951
Differential Revision: https://phabricator.services.mozilla.com/D150433
On Android we previously added a rendering path using the
SurfaceControl API, in order to work around an Android OS bug when
recovering from a GPU process crash. Unfortunately the Magnifier
widget (shown when moving a text selection caret) does not work when
rendering using SurfaceControl.
This patch makes it so that we temporarily disable the SurfaceControl
path when a text selection is active, allowing the Magnifier to work.
Unfortunately this means that if a GPU process crash occurs while
there is an active selection we will be unable to recover. Hopefully
this turns out to be a relatively rare occurence.
Differential Revision: https://phabricator.services.mozilla.com/D153454
Windows toast actions (buttons) override the launch argument. The launch arguments are necessary for the notification server to reconstruct the source of the toast, therefore we prepend it to the action argument.
Differential Revision: https://phabricator.services.mozilla.com/D152466
Adds a GUID to the notification's launch attribute too verify a timeout dismissed event doesn't remain in the Action Center.
Remove event hiding to allow notifications to be acted upon after the page or browser is closed.
Differential Revision: https://phabricator.services.mozilla.com/D151741
Adds `program` and `profile` paths to Windows toast notifications so that the COM server can reconstruct the origin in order to relaunch the application.
Differential Revision: https://phabricator.services.mozilla.com/D151740
For MSIX packages, the package AUMID is used.
For NSIS/MSI installs, AUMID is retrieve from HKCR.
For portable builds, the registry is updated at runtime to populate icons, display name, and the COM server.
The COM server has been registered as will be implemented using DllSurrogate; this allows us to offload managing the eventloop and lifetime of the COM server to dllhost.exe, and minimizes the added code complexity.
The COM server is loaded as a separate executable from the sending process to prevent issues that would occur when multiple instances of the sending process (e.g. profiles running in parallel) try to stand up parallel COM servers. The separated COM executable also allows for multiple applications to share a common COM server.
Bonus: fixes Bug 1500054, Bug 1766095, and Bug 1743424.
Differential Revision: https://phabricator.services.mozilla.com/D151739
After the previous changes there was only one consumer left of the Shmem
version of GetSurfaceData, which could easily be changed to use BigBuffer,
removing the need for that overload.
After that consumer is removed, the interface was also simplified as the
generic logic in the implementation was no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D151854
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
After the previous changes there was only one consumer left of the Shmem
version of GetSurfaceData, which could easily be changed to use BigBuffer,
removing the need for that overload.
After that consumer is removed, the interface was also simplified as the
generic logic in the implementation was no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D151854
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
This patch shouldn't change behavior. The Cocoa changes in particular
just save useless frame tree walks, since ThemeColors already computes
the color scheme in ColorSchemeForWidget.
Differential Revision: https://phabricator.services.mozilla.com/D153424
Both Chrome and Edge on Windows also move the swipe-to-nav arrow icon, the
distance of move seems to be a fixed value, it doesn't depend on the browser
window size. So we also use a fixed value, 100px here.
Chrome on Mac also moves the icon, but in a slightly different way. The icon is
a semicircle shape, it never leaves the edge of the browser window even if it's
moving during swipe gestures. So we introduce a new preference named
"browser.swipe.navigation-icon-move-distance" to implement platform dependent
swipe-to-nav icon behaviors. As of now the value on platforms other than Windows
is zero so that the icon never moves on the platforms.
Differential Revision: https://phabricator.services.mozilla.com/D150433
Windows toast actions (buttons) override the launch argument. The launch arguments are necessary for the notification server to reconstruct the source of the toast, therefore we prepend it to the action argument.
Differential Revision: https://phabricator.services.mozilla.com/D152466
Adds a GUID to the notification's launch attribute too verify a timeout dismissed event doesn't remain in the Action Center.
Remove event hiding to allow notifications to be acted upon after the page or browser is closed.
Differential Revision: https://phabricator.services.mozilla.com/D151741
Adds `program` and `profile` paths to Windows toast notifications so that the COM server can reconstruct the origin in order to relaunch the application.
Differential Revision: https://phabricator.services.mozilla.com/D151740
For MSIX packages, the package AUMID is used.
For NSIS/MSI installs, AUMID is retrieve from HKCR.
For portable builds, the registry is updated at runtime to populate icons, display name, and the COM server.
The COM server has been registered as will be implemented using DllSurrogate; this allows us to offload managing the eventloop and lifetime of the COM server to dllhost.exe, and minimizes the added code complexity.
The COM server is loaded as a separate executable from the sending process to prevent issues that would occur when multiple instances of the sending process (e.g. profiles running in parallel) try to stand up parallel COM servers. The separated COM executable also allows for multiple applications to share a common COM server.
Bonus: fixes Bug 1500054, Bug 1766095, and Bug 1743424.
Differential Revision: https://phabricator.services.mozilla.com/D151739
For MSIX packages, the package AUMID is used.
For NSIS/MSI installs, AUMID is retrieve from HKCR.
For portable builds, the registry is updated at runtime to populate icons, display name, and the COM server.
The COM server has been registered as will be implemented using DllSurrogate; this allows us to offload managing the eventloop and lifetime of the COM server to dllhost.exe, and minimizes the added code complexity.
The COM server is loaded as a separate executable from the sending process to prevent issues that would occur when multiple instances of the sending process (e.g. profiles running in parallel) try to stand up parallel COM servers. The separated COM executable also allows for multiple applications to share a common COM server.
Bonus: fixes Bug 1500054, Bug 1766095, and Bug 1743424.
Differential Revision: https://phabricator.services.mozilla.com/D151739
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
Destroying the IAudioSessionControl has concurrency issues with audio playback that require it to be done on the main thread. We have been trying to create a new AudioSessionControl on a background thread while this happens but some AudioSessionControl internals/dependencies are not thread safe. In order to avoid concurrency crashes, we destroy the old IAudioSessionControl on the main thread, then dispatch the restart to a background (MTA) thread asynchronously.
Differential Revision: https://phabricator.services.mozilla.com/D152302
A deadlock issue with our main thread audio playback handling arises when we try to destroy the AudioSessionControl from the MTA, despite it being an MTA object. We therefore dispatch its destruction to the main thread (STA) so the deadlock is impossible. In order to use it from the STA, we should wrap it in an AgileReference.
Differential Revision: https://phabricator.services.mozilla.com/D152301
Concurrent operations in the MTA make the required lifetime of the AudioSession complex. In particular, it cannot be known when/if any methods are currently queued or being executed (in particular, Start). In order to make this safe, we keep the AudioSession at least as long as XPCOM is running background threads.
This patch also removes a long-defunct state machine and does some basic code cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D152300
- Don't delete layer manager when nsWindow is unrealized but leave that to Destroy() when it's actually deleted.
Only disable rendering in ReleaseGdkWindow().
- Create msWindow with enabled composition
- Use single nsWindow::ConfigureCompositor() routine to configure compositor and use it from
ConfigureGdkWindow() and SetCompositorWidgetDelegate().
Depends on D153206
Differential Revision: https://phabricator.services.mozilla.com/D153207
These don't get styles early enough to make a shadow decision before Show().
This also matches the previous behavior (nothing would set
nsWidgetInitData::mDropShadow for these windows), so this is the less risky
fix.
It seems somewhat sketchy to use a popup window for these to begin with (Linux
for example maps them to a toplevel Window, at least on Wayland...), but let's
not change too much right now.
The hbrBackground change is a no-op because we can't have a brush before
Create() is called, we update it in SetBackgroundColor().
Differential Revision: https://phabricator.services.mozilla.com/D153095
When mCompositorWidgetDelegate is changed we need to recreate compositor and Wayland vsync. In this patch we do:
- Make mCompositorWidgetDelegate hard requirement for Wayland vsync source to avoid hidden failure.
- Stop Wayland vsync source at nsWindow::SetCompositorWidgetDelegate() when we're going to release or change mCompositorWidgetDelegate.
- Start Wayland vsync source at nsWindow::SetCompositorWidgetDelegate() when there's a new mCompositorWidgetDelegate to make sure vsync uses
recent one.
- Set new window config (XWindow, shape, widget) and resume compositor at nsWindow::SetCompositorWidgetDelegate() when new mCompositorWidgetDelegate is assigned to widget.
- As it's possible that mCompositorWidgetDelegate is missing in nsWindow::ConfigureGdkWindow() use moz_container_wayland_add_initial_draw_callback() to call mCompositorWidgetDelegate->EnableRendering() & WaylandStartVsync(). That ensures we won't silently fail to set up nsWindow for rendering.
Differential Revision: https://phabricator.services.mozilla.com/D152693
Enable composition only once when nsWindow is created and don't stop compositon until a window is destroyed.
Remove COMPOSITOR_PAUSED_MISSING_WINDOW as we don't manage compositing for hidden windows any more.
Differential Revision: https://phabricator.services.mozilla.com/D152690
nsWindow::SetCompositorWidgetDelegate() should not control compositor state as nsWindow::SetCompositorWidgetDelegate() itself is called by nsBaseWidget::CreateCompositor()/nsBaseWidget::DestroyCompositor().
In this patch we remove compositor pause/resume from nsWindow::SetCompositorWidgetDelegate() and update only GdkWindow/XWindow stored in remote widget.
Differential Revision: https://phabricator.services.mozilla.com/D152687
When the user wishes to open the window with the mouse, the shell sends NIN_SELECT.
We could continue to use WM_LBUTTONUP there, but the semantic notification is probably better.
When the user presses the space/enter key to open the window, the shell sends NIN_KEYSELECT.
When the user activates the context menu either with the mouse or the keyboard (applications/shift+f10 key), the shell sends WM_CONTEXTMENU.
Differential Revision: https://phabricator.services.mozilla.com/D152234
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
Use a larger stack size on macOS 13 for the Wifi monitor thread to accommodate Core WLAN code allocating 217K+ on the stack.
Differential Revision: https://phabricator.services.mozilla.com/D152555
From Bug 1774869, current events watching by WindowOcclusionCalculator is not enough. EVENT_SYSTEM_CAPTUREEND event is added like chromium.
Differential Revision: https://phabricator.services.mozilla.com/D152250
With this patch moz_container_wayland_surface_lock() always locks MozContainer and needs to be paired with moz_container_wayland_surface_unlock() even if it fails and returns nullptr.
Split moz_container_wayland_add_initial_draw_callback() to two new functions:
- moz_container_wayland_add_initial_draw_callback_locked() is called on locked container and only adds draw callback.
It asserts when MozContainer is already to draw as we don't expect it.
- moz_container_wayland_add_or_fire_initial_draw_callback() is called on unlocked container as it has it's own lock.
It behaves as original moz_container_wayland_add_initial_draw_callback(), i.e. stores draw callback when MosContainer is not visible
and fires draw callback when we're ready to draw.
Differential Revision: https://phabricator.services.mozilla.com/D152276
Add a pref for MouseEvent.region since that wasn't un-exposed. No other
browser supports it so we can probably safely remove it, but just in
case.
Differential Revision: https://phabricator.services.mozilla.com/D152274
Manage their shadow style per-window instead. It is a bit unfortunate, but
alas, seems to work, and we had existing code for various workarounds, so it's
not too gross.
The menulist special-case isn't needed anymore, menulists always have
eTransparencyTransparent nowadays on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D151994
A bug is not reported related to "zero copy hardware decoded video" on Windows. Zero video frame copy needs "reuse decoder device ". And it is already enabled on Nightly / Early Beta by Bug 1773714.
RadeonBlockNoVideoCopy is renamed to RadeonBlockZeroVideoCopy
Differential Revision: https://phabricator.services.mozilla.com/D152139
In some non-standard configurations we unexpectedly end up in this paths
without a GBM device - one example being the GPU process. Fail cleanly
instead of crashing in those cases, triggering fallback paths.
Context: in the past DMABuf usage was tightly coupled to GBM. Since the
introduction of the surfaceless and device EGL platforms that is not
longer the case, thus we can't make checks like `IsDMABufWebGLEnabled()`
depend on the presence of a GBM device.
Optimally all affected cases get fixed eventually. Until then and also
for future cases it makes sense to fail softly.
Differential Revision: https://phabricator.services.mozilla.com/D152173
This simplifies a bit the tabbrowser/tab switcher code, and makes it
work in all windows.
The WPT failures are due to bug 1780212.
Differential Revision: https://phabricator.services.mozilla.com/D151822
Just like it manages content, so that we stop chrome animations and such
in hidden or fully-occluded windows too. This already happened on macOS
for minimized windows via PauseCompositor, but this should be better and
more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D151818
VsyncDispatcher::NotifyVsync can be called from two different threads
at the same time, if it just swapped out its vsync source and the old
vsync source is still notifying it. So we need to protect mVsyncSkipCounter
behind a lock.
Differential Revision: https://phabricator.services.mozilla.com/D148958
Just like it manages content, so that we stop chrome animations and such
in hidden or fully-occluded windows too. This already happened on macOS
for minimized windows via PauseCompositor, but this should be better and
more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D151818