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
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
Add synthesizeMockDragAndDrop test function to test elements
drag-dropped inside of Firefox. This uses the new MockDragService to
avoid native DND. It is a more-complete variant of synthesizeDragAndDrop
and synthesizePlainDragAndDrop. It works by:
1. Creating the environment for the test.
2. Gathering coordinates of the source and target elements from their
respective content processes.
3. Setting up event handlers on the elements to detect any relevant events
they may receive. This allows us to detect not only events that aren't sent
when they should be but also events that are sent that shouldn't be.
4. Synthesizing mouse events to initiate the drag-session. This and
the remaining steps work by first telling the relevant content process(es)
what events to expect (and which not to), then sending the event, and
finally collecting the results and submitting them to mochitest.
5. Synthesizing drag events with the MockDragServiceController, to emulate
the behavior of (Windows) native drag-and-drop. This is a coarse
approximation of the Win32 API DoDragDrop.
6. Cleaning up the event handlers.
The test does not yet try to mock things like the drag cursor image, although
that should be possible without native DND behavior. The same is true for
some more minor aspects of the platform-specific behavior of our DND.
Differential Revision: https://phabricator.services.mozilla.com/D205641
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
`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
It appears that the Element member may have been creating a reference
cycle passing through the new strong WindowGlobalParent::Manager()
reference.
This patch also removes an unused member from BrowserParent which
otherwise may have needed to be cycle-collected.
Differential Revision: https://phabricator.services.mozilla.com/D207170
There are a few IPDL actors which are cycle-collected, including `PBrowser`,
`PContent`, and `PWindowGlobal`.
This patch adds support for these actors to traverse and unlink the new strong
Manager() reference added by IPDL, allowing cycles containing these actors to
be properly unlinked and avoiding leaks.
Differential Revision: https://phabricator.services.mozilla.com/D198629
Previously there was dead code handling DeallocPvsyncParent which hasn't been
called since PVsync was made refcounted. The new logic handles the reference
within IPC, and delays some initialization to the proper constructor.
Differential Revision: https://phabricator.services.mozilla.com/D198627
There are a few IPDL actors which are cycle-collected, including `PBrowser`,
`PContent`, and `PWindowGlobal`.
This patch adds support for these actors to traverse and unlink the new strong
Manager() reference added by IPDL, allowing cycles containing these actors to
be properly unlinked and avoiding leaks.
Differential Revision: https://phabricator.services.mozilla.com/D198629
Previously there was dead code handling DeallocPvsyncParent which hasn't been
called since PVsync was made refcounted. The new logic handles the reference
within IPC, and delays some initialization to the proper constructor.
Differential Revision: https://phabricator.services.mozilla.com/D198627
Mouse events can be generated from other mouse events, e.g. mouseout event, and
these events can originate from different widgets, such as the notification
panel. In such case, we need to adjust the coordinates when sending to content
process.
Differential Revision: https://phabricator.services.mozilla.com/D197715
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
This involved moving ApplyCache from the .h into the .cpp because now that the class is no longer a template, forward declaration of DocAccessibleParent is not sufficient.
Differential Revision: https://phabricator.services.mozilla.com/D181852
