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
nsBaseDragService keeps track of the processes that might need to cancel a drag with EndDragSession and this is technically correct since the drag session is a singleton in the child process, but this series of patches changes those sessions to be per-PuppetWidget/BrowserChild. This allows content processes to distinguish which of its browsers is engaged in a drag.
Differential Revision: https://phabricator.services.mozilla.com/D211062
Updates each client of the nsContentUtils method to get the right drag session -- the one for the widget that is currently the source or target of the drag session.
The change to nsDOMWindowUtils::DispatchDOMEventViaPresShellForTesting() supports the change to WidgetDragEvent::InitDropEffectForTests() and enabled a
large number of test fixes in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D211067
`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
The builtin legacy IME of Windows to type a Unicode with typing a code point
causes consumed `eKeyDown` events while typing the code point, i.e., without
`eKeyPress` (FYI: The consumed state is not exposed to the web, it's used only
in chrome UI for the compatibility with Chrome). Then, `BrowserChild` store
whether the last `eKeyDown` was consumed or not to prevent the following
`eKeyPress`. Finally, a `eKeyPress` event is fired to input the Unicode
character after `eKeyUp` for `Alt`. The stored value is set to new value only
when another `eKeyDown` event is sent from the parent process. Therefore,
the last digit inputting `eKeyDown` causes `BrowserChild` thinking the last
`eKeyDown` is consumed so that the last `eKeyPress` is not dispatched.
This patch makes `BrowserChild` to store the `code` value of the last consumed
`eKeyDown` and check the `code` value to consider whether coming `eKeyPress`
should be or not be dispatched to `PresShell` and the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D207957
The builtin legacy IME of Windows to type a Unicode with typing a code point
causes consumed `eKeyDown` events while typing the code point, i.e., without
`eKeyPress` (FYI: The consumed state is not exposed to the web, it's used only
in chrome UI for the compatibility with Chrome). Then, `BrowserChild` store
whether the last `eKeyDown` was consumed or not to prevent the following
`eKeyPress`. Finally, a `eKeyPress` event is fired to input the Unicode
character after `eKeyUp` for `Alt`. The stored value is set to new value only
when another `eKeyDown` event is sent from the parent process. Therefore,
the last digit inputting `eKeyDown` causes `BrowserChild` thinking the last
`eKeyDown` is consumed so that the last `eKeyPress` is not dispatched.
This patch makes `BrowserChild` to store the `code` value of the last consumed
`eKeyDown` and check the `code` value to consider whether coming `eKeyPress`
should be or not be dispatched to `PresShell` and the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D207957
This reference created a cycle after the strong Manager() reference added in an earlier part.
With the reference removed, the VsyncChild will be kept alive via the IPC link
instead, and will be torn down when the IPDL actor is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D198626
If session history in the parent is enabled then session store only works
correctly if the platform collection code is turned on.
Differential Revision: https://phabricator.services.mozilla.com/D203375
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
This reference created a cycle after the strong Manager() reference added in an earlier part.
With the reference removed, the VsyncChild will be kept alive via the IPC link
instead, and will be torn down when the IPDL actor is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D198626
Reflect modifiers to chromeFlags and nsIBrowserDOMWindow::OPEN_* location,
to perform the equivalent of BrowserUtils.whereToOpenLink in window.open with
modifier keys.
Differential Revision: https://phabricator.services.mozilla.com/D197864
Pass UserActivation::Modifiers from nsGlobalWindowOuter::OpenInternal
to nsPIWindowWatcher.openWindowWithRemoteTab, through the following interfaces
and protocol:
* nsPIWindowWatcher.openWindow2
* nsIWindowProvider.provideWindow
* PContent.CreateWindow or PContent.CreateWindowInDifferentProcess
* nsPIWindowWatcher.openWindowWithRemoteTab
Differential Revision: https://phabricator.services.mozilla.com/D197863
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
- Ensure that we hold a strong reference to the APZ event state before
calling ProcessSingleTap, as ProcessSingleTap fires events.
- Mark ProcessSingleTap as MOZ_CAN_RUN_SCRIPT since it can fire events.
Differential Revision: https://phabricator.services.mozilla.com/D190228
Test by Gijs. Note that I removed the .isActive assertion, because this doesn't
affect activeness.
We could make that change too, but that's a bigger change, and I think we want
to do this regardless.
The CAN_RUN_SCRIPT annotations are obsolete (they come from bug 1582042
which directly fired docshell activity events, but that's not true
anymore, bug 1635914 changed the setup a bit later).
Differential Revision: https://phabricator.services.mozilla.com/D185643
This should not be needed anymore. We no longer need to "ack" an epoch,
since there's no epoch.
Make the logic to trigger a paint and request composite a bit more
generic. That doesn't change behavior right now, because our visibility
state is tied to mRenderLayers, but without this change setting
renderLayers = true on a display: none iframe will trigger a useless
paint after bug 1847584.
Differential Revision: https://phabricator.services.mozilla.com/D187293
This seems to work, and turns out I need to fix this before bug 1847584,
because the epoch handling breaks with those patches in the case
customize mode sets display: none on browser elements.
Instead of dealing with epochs, just always report the last "has layers"
state to BrowserParent. This is both simpler and more reliable (there
were a couple hacks in WebRenderBridgeParent to make sure we notified
even though a transaction failed).
AsyncTabSwitcher pretty much already deals with this correctly because
it already needs to deal with browsers that already have layers, we only
had to loosen some assertions for potentially previous messages which
are fine.
Differential Revision: https://phabricator.services.mozilla.com/D187203
Test by Gijs. Note that I removed the .isActive assertion, because this doesn't
affect activeness.
We could make that change too, but that's a bigger change, and I think we want
to do this regardless.
The CAN_RUN_SCRIPT annotations are obsolete (they come from bug 1582042
which directly fired docshell activity events, but that's not true
anymore, bug 1635914 changed the setup a bit later).
Differential Revision: https://phabricator.services.mozilla.com/D185643
