Eliminate a possible race-condition wherein multiple file-dialogs fight
over disabling the root window, possibly reenabling it early.
Differential Revision: https://phabricator.services.mozilla.com/D201775
This is to be landed after the merge. I think this is better / more
consistent, and avoids relying on mis-documented window style flags in
MSDN.
Differential Revision: https://phabricator.services.mozilla.com/D201894
Android's drag and drop API will set a dropped item on `drop` event. But other
platforms will be set during `dragstart` event.
Editor's drag and drop event listener checks current dropped item on some
events such as `dragover` event in
`EditorEventListener::DragEventHasSupportingData`. Since there is no way to
set dropped item on `dragover` event, GeckoView will set temporary dropped
item with MIME type.
Differential Revision: https://phabricator.services.mozilla.com/D200618
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
WillPaintWindow() spins event loop which can lead to any action related to nsWindow - it can be hid, shown or destroyed.
If the nsWindow visibility is changed, compositor/renderer is deleted and we need to get it again.
Differential Revision: https://phabricator.services.mozilla.com/D200272
nsWindow::mGdkWindow is set/reset when nsWindow becomes visible/invisible so we need to update GdkWindow in IMContextWrapper according to it.
Differential Revision: https://phabricator.services.mozilla.com/D200270
- Remove gtk_widget_get_window() where it's possible and use mGdkWindow directly.
- Check gtk_widget_get_window() return values to ensure we don't use null GdkWindow.
Differential Revision: https://phabricator.services.mozilla.com/D200269
We can't set mGdkWindow at GetCompositorWidgetInitData() is window is unmapped. Rather we provide null XWindow and disable rendering and update XWindow afer OnMap event.
Differential Revision: https://phabricator.services.mozilla.com/D200268
- Unmap MozContainer from it's unmap handler and don't use mShell handler for it
- Disable rendering to MozContainer before we unmap it
Differential Revision: https://phabricator.services.mozilla.com/D199085
This seems hard to reliably test... Basically, this forces all windows
HCM to use "light" system colors for non-native drawing, the same way we
do for system color resolution.
Differential Revision: https://phabricator.services.mozilla.com/D201205
We no longer have non-transparent popups nor set the window region to
get clipping, instead rendering our own shadows and decorations, so this
code is just not needed anymore.
Depends on D200508
Differential Revision: https://phabricator.services.mozilla.com/D200612
Bug 1870512 removed top level windows with WindowType::Popup, instead
replacing it with an "alert" feature for the only use of them that we
had.
Turns out that on Windows they need a bit more special handling than I
thought, so this patch uses the alert boolean to fix two regressions
(that alerts now create taskbar icons, and that they steal focus).
Remove mIsForMenuPopupFrame since that is now a synonym with
WindowType::Popup.
Remove also the dialog vs. toplevel difference of using
WS_EX_DLGMODALFRAME, since that doesn't seem to have an effect at all on
windows 10+.
Differential Revision: https://phabricator.services.mozilla.com/D200508
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
Most are brought over straightforwardly, their Telemetry callsites reworded
to use Glean, with mirroring to the Telemetry probes taken care of by the Glean
Interface For Firefox Telemetry (see the telemetry_mirror property).
There were some special cases:
* HistogramStopwatch becomes GleanStopwatch.
After migration it was only serving Glean consumers.
Could've used standard Glean APIs, but having something to hold the TimerIds
was convenient.
* GV_STARTUP_MODULES_MS was removed.
It was configured to only report for the `firefox` product,
but could only have a value in `geckoview_streaming`,
so never reported data.
* MEDIA_DECODING_PROCESS_CRASH was removed.
It was configured to only report for the `firefox` product,
but could only have a value in `geckoview_streaming`,
so never reported data.
* GV_CONTENT_PROCESS_LIFETIME_MS was removed.
It was configured to only report for the `geckoview_streaming` product,
meaning it only reported data when used with GVST to reach the Glean
`geckoview.content_process_lifetime` metric.
This is now accomplished directly.
* GV_STARTUP_RUNTIME_MS was removed.
Though it was configured to report data for both `firefox` and
`geckoview_streaming` products, it only ever had values in geckoview.
Its data continues to be reported via `geckoview.startup_runtime`.
* gecko.version and gecko.build_id (Scalars) were removed.
In Firefox Desktop this information is available in the `application`
section of the Environment.
In geckoview-using products, this information continues to be available via
`geckoview.version` and `geckoview.build_id`.
* GV_STARTUP_RUNTIME_MS and GV_CONTENT_PROCESS_LIFETIME_MS are handled oddly.
Since those probes were recorded in the Java portion of the code,
and that portion doesn't include Glean,
we use `nativeAddHistogram` to relay the samples for those two pieces of
instrumentation.
If there will be more instrumentation landing in that part of the code,
I recommend you review the instructions for including the Glean SDK in a
library, and retire this use of JNI.
Differential Revision: https://phabricator.services.mozilla.com/D200094
Eliminate `WindowEnabler` by folding it into `nsWindow::PickerOpen()`
and `nsWindow::PickerClosed()`. This avoids the implicit assumption that
multiple instances are created and destroyed in LIFO order.
Differential Revision: https://phabricator.services.mozilla.com/D200742
Remove an unnecessary member function from AutoWidgetPickerState.
Additionally, use a safer method of getting the underlying nsWindow than
`static_cast`, and add some thread-safety assertions in
nsWindow::Picker{Open,Closed}().
No functional changes on the happy path.
Differential Revision: https://phabricator.services.mozilla.com/D200741
This is a regression by bug 1586471.
We should use ReceiveInputEvent for all drag events on desktop.
Also, GV issue is bug 1878819 since we have to consider more when APZ
controller thread and main thread are different. But GV doesn't turn
on fission yet.
And, there is no way to add tests for native drag and drop operations.
Differential Revision: https://phabricator.services.mozilla.com/D200783
As far as I've tested on Win 11, we can put it off to load it when first needed
of the keyboard layout data. `ToUnicodeEx` API changes the dead key state and
it's called a lot in `KeyboardLayout::LoadLayout`, however, this patch does
not newly call `LoadLayout` after `TranslateMessage` API at least while handling
a key message. Therefore, this should be safe but regressions of this change
could be serious, so this makes it enabled only in early beta and earlier for
now.
Differential Revision: https://phabricator.services.mozilla.com/D200600
DestroyNativeWindow() is called for permanent window destruction, but it
is also called for transitory window recreated in HideWindowChrome().
When the nsCocoaWindow itself is also expected to be destroyed, it's
useful to clear out transitions. But when the nsCocoaWindow is expected
to persist (with a new mWindow instance), it's unhelpful to clear the
transitions, because emulated fullscreen relies on transition
continuity.
This change further simplifies DestroyNativeWindow so it does only the
bare-minimum, always-needed things before forgetting mWindow and its
delegate. The higher-level concern of clearing out transitions is
factored out into a new function CancelAllTransitions, which is invoked
by callers when appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D200215
As far as I've tested on Win 11, we can put it off to load it when first needed
of the keyboard layout data. `ToUnicodeEx` API changes the dead key state and
it's called a lot in `KeyboardLayout::LoadLayout`, however, this patch does
not newly call `LoadLayout` after `TranslateMessage` API at least while handling
a key message. Therefore, this should be safe but regressions of this change
could be serious, so this makes it enabled only in early beta and earlier for
now.
Differential Revision: https://phabricator.services.mozilla.com/D200600
A few stand-in colors were missing dark variants, causing unexpected light elements such as non-native theme tooltips on Linux.
Differential Revision: https://phabricator.services.mozilla.com/D200598
WillPaintWindow() spins event loop which can lead to any action related to nsWindow - it can be hid, shown or destroyed.
If the nsWindow visibility is changed, compositor/renderer is deleted and we need to get it again.
Differential Revision: https://phabricator.services.mozilla.com/D200272
Ray Kraesig
Gijs Kruitbosch
stransky
Emilio Cobos Álvarez
Makoto Kato
Jan Horak
Greg Stoll
Cristian Tuns
Perry McManis
Kelsey Gilbert
Masayuki Nakano
Brad Werth
Stanca Serban
Cosmin Sabou
Tom Ritter
Sandor Molnar
Sam Johnson
Tooru Fujisawa