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
MustUpdateDataTransfer is a simple function that makes more sense on
nsIDragSession.
MaybeAddBrowser records BrowserParents for processes with existing drag
sessions. There may be such processes before the parent process
even has a drag session, so they cannot be tied to drag sessions. We tie
them to the drag service, until the service creates a drag session in
the process, at which point we move them to the drag session. Since
the session and service are still the same object and each now has methods
with these names, we leave part of session's implementation commented out
so that we run correctly instead of looping infinitely. The code is
exposed when the objects separate later in the patch series.
Finally, the implementation of TakeSessionBrowserListFromService currently
amounts to a nop, but it will have substace when the service and session
are separated.
Differential Revision: https://phabricator.services.mozilla.com/D211081
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
`input` event listeners may be async functions and may set the text control
element value after the editor ends dispatching an `input` event. Even in this
case, the `input` event listener should not be called recursively by committing
composition which is caused by setting the value because the value is
overwritten by the setting value which was intended by the web app.
Unfortunately, we cannot check whether the value setter is an async `input`
event listener. Therefore, we need to suppress `input` events even after the
editor ends dispatching `input` event.
On the other hand, we should not suppress `input` event if the value is set
by a `compositionupdate` event listener which runs before the editor starts
handling the latest composition change because once we do that, the app won't
receive `input` event for the composition. Therefore, we should not suppress
the editor starts handling the composition change (including during
`beforeinput` event dispatching, but the `beforeinput` is not cancelable, so,
the result will be odd, therefore, we have no tests for the cases).
Therefore, this patch adds a new method to `TextComposition` to make
`TextControlState::SetValue` can check whether the editor is handling the
latest composition change or after that. So, during composition, setting
value should cause `input` events between `TextComposition` starts dispatching a
`compositionupdate` event and `EditorBase` starts handling `eCompositionChange`
event which is dispatched after `compositionupdate`.
Differential Revision: https://phabricator.services.mozilla.com/D214676
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
`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
Chrome/Android doesn't dispatch composition event when
`InputConnection.commitText` is called from input method without composition.
So we should use same way as compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D210197
I would like to move data class from WebAuthnTokenManager to new class
since WebAuthnTokenManager may becomes complex when we add Credential
Manager support.
Differential Revision: https://phabricator.services.mozilla.com/D207500
When using mouse on GeckoView, dblclick event isn't fired. Android doesn't
have a state of double click for mouse, so we have to emulate it like
Windows widget.
The default of timeout values are from android.view.GestureDetector's double
tap.
Differential Revision: https://phabricator.services.mozilla.com/D209654
When the Android frontend attempts to pause or resume the compositor
there is a chance this may fail. When this happens, the compositor
will automatically be reinitialized. However, it will currently be
reinitialized in the previous state, not the state the frontend
intended. For example, if the compositor fails to resume then it will
be reinitialized but remain in a paused state, displaying a blank
screen to the user.
To avoid this, we update the value of mCompositorPaused prior to
attempting to pause or resume the compositor. This means when
NotifyCompositorCreated eventually gets called, it knows the correct
state in which to initialize the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D202165
When the Android frontend attempts to pause or resume the compositor
there is a chance this may fail. When this happens, the compositor
will automatically be reinitialized. However, it will currently be
reinitialized in the previous state, not the state the frontend
intended. For example, if the compositor fails to resume then it will
be reinitialized but remain in a paused state, displaying a blank
screen to the user.
To avoid this, we update the value of mCompositorPaused prior to
attempting to pause or resume the compositor. This means when
NotifyCompositorCreated eventually gets called, it knows the correct
state in which to initialize the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D202165
When the Android frontend attempts to pause or resume the compositor
there is a chance this may fail. When this happens, the compositor
will automatically be reinitialized. However, it will currently be
reinitialized in the previous state, not the state the frontend
intended. For example, if the compositor fails to resume then it will
be reinitialized but remain in a paused state, displaying a blank
screen to the user.
To avoid this, we update the value of mCompositorPaused prior to
attempting to pause or resume the compositor. This means when
NotifyCompositorCreated eventually gets called, it knows the correct
state in which to initialize the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D202165
By default, AttachCurrentThread() overwrites the existing thread name
with "Thread-<n>", making it hard to identify these threads in a
debugger. By supplying the existing thread name as an argument to
AttachCurrentThread, we ensure that the thread keeps its name as
desired.
Differential Revision: https://phabricator.services.mozilla.com/D207559
This is actually the removal of two different deprecated geckoview adapters:
GV Persistence, and GV Streaming Telemetry.
GVP has been out of use for four years. GVST has had all of its data migrated
to direct Glean use back in February and has been deprecated for two versions.
Differential Revision: https://phabricator.services.mozilla.com/D207475
Now that -Wc++2a-compat is no longer enabled (bug 1887580), we don't need these pragmas disabling -Wc++2a-compat warnings about u8"" string literals' type changing from const char[] in C++17 to const char8_t[] in C++20.
Depends on D206742
Differential Revision: https://phabricator.services.mozilla.com/D206743
Make the "is hidden due to non-collapsed selection" use the regular
caret-hiding mechanism, so that we make sure nsCaret and paint are
consistent on their caret visibility.
As part of this simplification:
* Remove LookAndFeel::IntID::ShowCaretDuringSelection, it's 0 on all
platforms.
* Remove nsCaret::IsMenuPopupHidingCaret. Is really broken as per the
comments (it assumes single-process mode, doesn't deal with shadow
dom, and it's not like it's particularly useful anyways since the
menu popup could be semi-transparent or what not).
Differential Revision: https://phabricator.services.mozilla.com/D205557
This duplicates existing HDR checks in gfxPlatformMac and
gfxWindowsPlatform. A later part of this patch series will remove that
redundant code, as it replaces calls to gfxPlatform functions with calls
to ScreenManager functions.
Differential Revision: https://phabricator.services.mozilla.com/D203670
Currently webgpu is enabled by default on Nightly Android. As it is
currently receiving no testing at all, we should disable it by default
by adding a blocklist entry. Adventurous souls will still be able to
enable it by setting the pref gfx.webgpu.ignore-blocklist=true.
Differential Revision: https://phabricator.services.mozilla.com/D205300
This duplicates existing HDR checks in gfxPlatformMac and
gfxWindowsPlatform. A later part of this patch series will remove that
redundant code, as it replaces calls to gfxPlatform functions with calls
to ScreenManager functions.
Differential Revision: https://phabricator.services.mozilla.com/D203670
This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
When compiled with -std=c++17, `u8""` string literals have type `const char[]`. When compiled with -std=c++20, `u8""` strings have type `const char8_t[]`. `JS_ReportErrorUTF8()` has no override for `char8_t` strings, so `u8"Invalid event data property %s"` at https://searchfox.org/mozilla-central/rev/5eedf36dc46f1683af7478c7adaf308ceb42911b/widget/android/EventDispatcher.cpp#132 fails to compile. In this case, there's no reason for `"Invalid event data property %s"` to be a `u8` string because it contains no non-ASCII characters that would be encoded incorrectly. Plus, clang's default character encoding for .cpp files is UTF-8, so `u8` is redundant here.
widget/android/EventDispatcher.cpp:125:7: error: no matching function for call to 'JS_ReportErrorUTF8'
125 | JS_ReportErrorUTF8(
| ^~~~~~~~~~~~~~~~~~
obj-aarch64-unknown-linux-android/dist/include/js/ErrorReport.h:465:27: note: candidate function not viable: no known conversion from 'const char8_t[31]' to 'const char *' for 2nd argument
465 | extern JS_PUBLIC_API void JS_ReportErrorUTF8(JSContext* cx, const char* format,
| ^ ~~~~~~~~~~~~~~~~~~
Differential Revision: https://phabricator.services.mozilla.com/D200553
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
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
Gregory Pappas