This patch moves the call to BaseWindow::Destroy() and ::OnDestroy() to
the end of nsCocoaWindow::Destroy(). It adds a death grip on this before
remove this from mParent. This should keep the window in a more stable
state throughout the function scope.
Differential Revision: https://phabricator.services.mozilla.com/D216066
This is a temporary measure. We would like to destroy the native window
here, but we want to see the effect of removal on crash volume.
This patch also moves the call to BaseWindow::OnDestroy() to the end of
::Destroy(). This is necessary to get tests to pass. It may also be the
real fix for this Bug.
Differential Revision: https://phabricator.services.mozilla.com/D216066
macOS offers an enum, NSTrackingInVisibleRect, which keeps the tracking
area up-to-date with the visible area of the window. This patch adds
this enum to our tracking area at window creation time, and removes the
code that was recreating the tracking area with every window resize.
It also moves the responsibility of creating and removing the tracking
area to the nsCocoaWindow, which keeps us from manipulating the tracking
area during deallocation.
Differential Revision: https://phabricator.services.mozilla.com/D219098
Keep supporting the pref makes a lot of `click`, `auxclick` and `contextmenu`
event creators complicated (and look messy). So, let's delete it as soon as
possible.
Differential Revision: https://phabricator.services.mozilla.com/D217225
macOs has the feature for auto-correction.
Other browsers already has this feature, and can control this by
`autocorrect` attribute [*1] that is still non-standard.
Since content script can modify source text for autocorrect by
any event handers, autocorrect is run when source text isn't
changed only.
The event order for this implementation is the following.
1. `keydown` event by space
2. `keypress` event by space
3. `beforeinput` event (`insertText`) by space
4. `input` event (`insertText`) by space
5. `beforeinput` event (`insertReplacementText`) by autocorrect
6. `input` event (`insertReplacementText`) by autocorrect
7. `keyup` event by space
Also, Safari's order is that input event for space is fired after
`insertReplacementText`. And, Chrome's is broken. When typing
`"omw"`, "w"'s keyup is fired after dismissing a picker. And they
don't use `insertReplacementText`.
And, Saferi can prevent this when calling `event.preventDefault()`
on `keypress` event handler for space/enter key. But I guess that
there is no way to get event handler calls `preventDefault()` from
widget side on Chrome process.
*1 https://github.com/whatwg/html/pull/5841
Differential Revision: https://phabricator.services.mozilla.com/D213512
This is a temporary measure. We would like to destroy the native window
here, but we want to see the effect of removal on crash volume.
Differential Revision: https://phabricator.services.mozilla.com/D216066
Unused for now, but pretty straight-forward.
Bug 1905257 has some code that actually uses it. This allows the
front-end folks to experiment with this effect for the sidebar.
Differential Revision: https://phabricator.services.mozilla.com/D216325
Split the class inheritance trees for nsIDragService and nsIDragSession.
Remember that, before the start of this patch series, the inheritance
diagram was:
nsDragService -> nsBaseDragService -> nsIDragService + nsIDragSession
and the only instance was a singleton. We switched it to:
nsDragService -> nsDragSession -> nsBaseDragService -> nsIDragService + nsBaseDragSession -> nsIDragSession
and maintained the singleton. This allowed us to allow us to move things to
the new classes without breaking behavior. We are done with that,
so we can now change the inheritance to its final form:
nsDragService -> nsBaseDragService -> nsIDragService
nsDragSession -> nsBaseDragSession -> nsIDragSession
Of course, we also need to properly construct and release the
nsIDragSessions (formerly part of the singleton), so that is done here as
well. That happens in nsBaseDrag[Service|Session] for parent process drags
and in nsDrag[Service|Session]Proxy for content. This is all fairly
straightforward, except in the case of gtk, where we need to change
some callback behavior.
Differential Revision: https://phabricator.services.mozilla.com/D211084
This is a straightforward move. It does take the liberty of breaking out an
EndDragSessionImpl method, which will be needed later.
Differential Revision: https://phabricator.services.mozilla.com/D211083
Creates the nsBaseDragSession class and moves nsIDragSession's methods and data
into it. This patch also does this for each platform-specific nsDragService
and the nsDragServiceProxy. The result is that the drag service and drag
session are still one object in both the main and child processes, and the
inheritance diagram for each platform implementation goes from its present
from:
nsDragService -> nsBaseDragService -> nsIDragService + nsIDragSession
to:
nsDragService -> nsDragSession -> nsBaseDragService -> nsIDragService + nsBaseDragSession -> nsIDragSession
(and similar for the nsDragServiceProxy).
At the end of this patch series, the objects will be separated and the
inheritance diagram will be as expected:
nsDragService -> nsBaseDragService -> nsIDragService
nsDragSession -> nsBaseDragSession -> nsIDragSession
There are no substantive changes here -- it's essentially all cut
and paste to prepare to smoothly sever the unwanted inheritance.
Differential Revision: https://phabricator.services.mozilla.com/D211072
Content process callers must call nsIDragService::GetCurrentSession with the
correct widget under the drag. For all callers, it is a sanity check.
Differential Revision: https://phabricator.services.mozilla.com/D211065
After bug 1867854, dialog windows on macOS no longer show desktop tinting on the window background. Since this requires a transparent Gecko background, the `-moz-mac-unified-toolbar-window` appearance added in bug 1870481 should be applied to every window. It has been renamed to reflect this.
Differential Revision: https://phabricator.services.mozilla.com/D215596
This comes back to bug 42557 and co. It only does something
half-reasonable on Windows (on macOS we just lie and make z-order
tracking be latest-active tracking), and given we don't use the special
zorder flags elsewhere I'm pretty sure we should be able to just rip
this off... On some DEs like Wayland we can't re-stack toplevel windows.
Differential Revision: https://phabricator.services.mozilla.com/D213602
It is important to remove the NSTrackingArea before the nsCocoaWindow is
deallocated. This patch ensures that we remember which NSView is holding
the tracking area and remove the tracking area from that view during
dealloc (as well as whenever the tracking area is updated).
Since the `trackingAreaView` property accessor returns a value based on
`contentView` or its superview, manipulations of either view will change
the return value of the accessor. We can't rely on it being consistent
throughout the lifetime of the window. This change ensures that we will
always remove the tracking area from the view that added it.
Differential Revision: https://phabricator.services.mozilla.com/D212949
This prevents one more way that `ProcessTransitions` might be called
after we'd rather it didn't. The `CancelAllTransitions` method is
updated to also cancel a dispatched call to `ProcessTransitions`. This
will prevent these dispatches from arriving after the `nsCocoaWindow`
has been deallocated.
Differential Revision: https://phabricator.services.mozilla.com/D212972
`eContextMenu` event may be fired from `widget`. Therefore, different from
`ePointerClick` and `ePointerAuxClick`, they may cross the process boundary,
may be handled by APZ and may be dispatched into the DOM after a delay.
Therefore, this patch is complicated than the previous patch. This adds
* New IPC message handlers for sending/receiving a `WidgetPointerEvent`
* New `DelayedPointerEvent` class and templated `MouseInput::ToWidgetEvent`
* `PresShell::EventHandler` handles `eContextMenu` as same as `WidgetMouseEvent`
Differential Revision: https://phabricator.services.mozilla.com/D213003
Though this is standard behavior for other windows, we want to
special-case this for PiP windows, which users expect to open in
resizable popups. This patch also prevents other popups and
alerts/dialogs from opening in fullscreen mode, which would be a bad
user experience.
Differential Revision: https://phabricator.services.mozilla.com/D210382
Maybe we should tweak the wording of the settings checkbox to more
strongly not implying that having it un-checked will not go through
links, but I'm not sure what wording could be best there.
Differential Revision: https://phabricator.services.mozilla.com/D209535
Most of this code is already dead. The native appearance on macOS
doesn't work on dark mode, and on Windows and Linux we are already
overriding it.
Add a first-column tree property to be able to align the inner borders
on macOS properly.
Differential Revision: https://phabricator.services.mozilla.com/D206526
Brad Werth
Gregory Pappas
Florian Quèze
Norisz Fay
Makoto Kato
Masayuki Nakano
Tom Schuster
Erich Gubler
Emilio Cobos Álvarez
Tim Huang
Otto Länd
David P
David Parks
Tamas Szentpeteri
Sam Johnson
Edgar Chen
palashgo
Jan-Niklas Jaeschke
Ting-Yu Lin
Sebastian Hengst
Brian Tsoi