In the patches above, we make some tooltips (which ignore mouse events)
actually overlap the mouse. That should be fine (and is fine on other
platforms) but Cocoa still sends mouseenter/leave events which confuse
the front-end.
This fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D197905
Instead of NSColor.textColor, use NSColor.controlTextColor, which is the color observed in native controls.
When these values were originally selected in bug 517412, the system colors were the same, but they have since diverged.
Differential Revision: https://phabricator.services.mozilla.com/D197125
No other platform does this. This comes from bug 413277, but positioning
windows (in particular popups) partially offscreen is desirable in some
cases (e.g., when drawing non-native shadows).
We have protections in place to prevent content from doing things like
what caused this code to be added.
Remove a cocoa-specific test for this, and tweak another test which has
a dependent window opened from an offscreen window, and the offscreen
window positioning happens right after the load event.
The window ends up on screen even without that tweak.
Differential Revision: https://phabricator.services.mozilla.com/D197903
No other platform does this. This comes from bug 413277, but positioning
windows (in particular popups) partially offscreen is desirable in some
cases (e.g., when drawing non-native shadows).
We have protections in place to prevent content from doing things like
what caused this code to be added.
Differential Revision: https://phabricator.services.mozilla.com/D197903
This seems like the right time to call DestroyNativeWindow since we are
hiding the window and destorying the nsBaseWidget -- there's not much
else that can happen to this window. Making this call here ensures that
the native window is not maintained on the screen waiting for the
destructor to be called during garbage collection.
Differential Revision: https://phabricator.services.mozilla.com/D197214
Before the first part of bug 1872399, that would use
WindowShadow::Default, which didn't create a vibrant effect etc, which
causes the background here.
Make it more explicit by calling this "Panel". The second part of
bug 1872399 already did this.
Differential Revision: https://phabricator.services.mozilla.com/D197648
The InsertText* code paths required an NSAttributedString instance but
only ever used their NSString representation. Callers nearly always have
an NSString, so this results in a lot of unnecessary NSAttributedString
allocations to satisfy this interface.
The primary caller is [ChildView insertText:replacementRange:], which
can receive either an NSString or an NSAttributedString string from the
NSTextInputClient protocol, but this is usually (always?) an NSString in
practice.
We can instead change these methods to receive NSString, simplifying the
callers and removing a bunch of short-lived NSAttributedString objects.
Differential Revision: https://phabricator.services.mozilla.com/D197451
-moz-window-shadow is a chrome-only property (not exposed to the web),
and chrome stylesheets only use the none value to disable the default
behavior.
Split the style property (default/none) from the actual widget behavior.
This is useful because I want to add a distinction between
natively-styled menupopups and other panels in the following commit.
While at it rename default to "auto" which is a more common name in CSS
for something like this.
We have no use case for removing the shadow of a top-level window, so
remove it to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D197454
The macOS menupopup corner radius was recently changed from 4px to 8px, but that does not quite match the system, which measures at 6px.
Differential Revision: https://phabricator.services.mozilla.com/D197408
Native tooltips, menus, and other opaque windows on macOS receive a border from the window server, which greatly improves their appearance with dark mode. Borderless windows, such as popups, do not receive this treatment by default. However, we have been receiving this treatment for non-native menupopups by setting an effect view wrapper as the window's content view. Extending this logic to also support tooltips allows the window server to provide the appropriate border for them as well.
macOS also provides some additional padding to native tooltips, so I have updated this as well.
Differential Revision: https://phabricator.services.mozilla.com/D197122
Instead of NSColor.textColor, use NSColor.controlTextColor, which is the color observed in native controls.
When these values were originally selected in bug 517412, the system colors were the same, but they have since diverged.
Differential Revision: https://phabricator.services.mozilla.com/D197125
By using a opaque-appearance widget (which is effectively what
appearance: -moz-dialog used to provide).
There's the question of whether we want the current vibrant titlebars,
but this restores the behavior precisely for now.
Differential Revision: https://phabricator.services.mozilla.com/D196712
This fixes various things, like sort arrows not working, even in regular
non-mixed-color-scheme settings, and is a lot less code.
The toolbarbutton appearance on the problematic case described in
comment 0 could get some work (the extra borders aren't exactly pretty),
but it's still a much better improvement.
Differential Revision: https://phabricator.services.mozilla.com/D195345
This allows removing the weird PiP special-case recently introduced.
After bug 1867854 the side effects it caused (transparent profile
manager etc) are no longer a concern.
This makes macOS widget behavior more similar to Windows and Linux.
Depends on D195297
Differential Revision: https://phabricator.services.mozilla.com/D195298
The window style mask docs don't seem to mention the restriction our
code mentioned.
Make the flags consistent with Gecko's to simplify the code and remove the
PiP special-case.
Depends on D195296
Differential Revision: https://phabricator.services.mozilla.com/D195297
This is not really needed.
It was never needed if you used background-color: transparent, which is what
the browser did to get sidebar vibrancy, fwiw.
Instead of applying transparency globally, opt-into it explicitly for
things that need it (the unified toolbar of the page info / library windows).
I checked the other things that were using it (wizard and updates.css)
and I don't see any rendering change with this change (tried showing the
update history from about:support, and the create profile wizard).
Depends on D195294
Differential Revision: https://phabricator.services.mozilla.com/D195295
In bug 1861954 I also removed the vibrancy of the places window.
Unlike the browser sidebar this one didn't have an explicit background
color. Add back a system color for the mac sidebar and use it in both
places. This matches the old -moz-mac-source-list color.
Differential Revision: https://phabricator.services.mozilla.com/D195294
Implement experimental transparent-on-hover behavior for the
picture-in-picture video player. This makes the popup player less of
a nuisance on smaller displays.
Tested on macOS, but should also work on Windows with small tweaks.
The behavior is hidden behind a pref:
media.videocontrols.picture-in-picture.seethrough-mode.enabled
Differential Revision: https://phabricator.services.mozilla.com/D193993
Thunderbird has a primary password modal show up before the app starts. It uses a raw event loop.
This needs to be changed to be after NSApp::run so it will be accessible, but that will be for a future fix.
Also, we need to do NSApp::stop: in applicationDidFinishLaunching asynchronously when processing URLs.
For some reason we end up in a bad state if we process events before NSApp::run and then call stop within
applicationDidFinishLaunching. The AppKit assertion says "NSApp with wrong _running count" even though we do not do
nested calls to NSApp::run.
Differential Revision: https://phabricator.services.mozilla.com/D194951
The old name is potentially misleading now that we implement 'page-orientation'
since that provides a new mechanism by which pages could end up orthoganal
to the sheet, but this method is very specifically about pages-per-sheet
induced rotation.
Differential Revision: https://phabricator.services.mozilla.com/D193989
This accidentally broke in 119 and nobody noticed on the whole nightly +
beta cycle (other than due to bug 1861669).
Given sidebars are not super-commonly used these days, this makes the
code a bit less fragile, and it still looks pretty good IMO. Also, since
we want to get rid of <xul:tree>s, this is one less thing to worry
about.
Depends on D192102
Differential Revision: https://phabricator.services.mozilla.com/D192103
When we call `nextEventMatchingMask` we send a "did launch app" notification to the OS workspace. If we do that before we call `[NSApp run]` accessibility isn't hooked up yet internally in AppKit and we fail to respond to a11y API queries.
Pumping Apple events is currently used for getting url requests in order to launch Firefox with the URLs loading correctly in a browser window. We can achieve the same result by using `application:openURLs:` in the delegate and calling `run` on the NSApp earlier and then stopping the loop in order to build the command line and finish initializing Firefox.
Also pumping the apple event queue should be deferred in `ProcessNextNativeEvent` until `[NSApp run]` is called.
Differential Revision: https://phabricator.services.mozilla.com/D184524
When we call `nextEventMatchingMask` we send a "did launch app" notification to the OS workspace. If we do that before we call `[NSApp run]` accessibility isn't hooked up yet internally in AppKit and we fail to respond to a11y API queries.
Pumping Apple events is currently used for getting url requests in order to launch Firefox with the URLs loading correctly in a browser window. We can achieve the same result by using `application:openURLs:` in the delegate and calling `run` on the NSApp earlier and then stopping the loop in order to build the command line and finish initializing Firefox.
Also pumping the apple event queue should be deferred in `ProcessNextNativeEvent` until `[NSApp run]` is called.
Differential Revision: https://phabricator.services.mozilla.com/D184524
Receiving the nsWindowDelegate methods windowDidFailToEnterFullScreen or
windowDidFailToExitFullScreen does not definitively indicate what the
final fullscreen state will be. This change stops listening for those
delegate methods and instead makes the later calls to
windowDidEnterFullScreen or windowDidExitFullscreen handle the case of
ending up in an unexpected state.
Differential Revision: https://phabricator.services.mozilla.com/D187316
Emilio Cobos Álvarez
Sam Johnson
Natalia Csoregi
Iulian Moraru
Brad Werth
Jon Parise
Stephen A Pohl
Sandor Molnar
Gijs Kruitbosch
Vsevolod Buzinov
Sylvestre Ledru
Stanca Serban
Jonathan Watt
Vsevolod Buzinov
Eitan Isaacson
Norisz Fay
Andrew McCreight
Edgar Chen
ran1
kriswright