Since this issue is too obvious, I am not even sure I am doing the right
thing. This looks like it should be discovered years ago....
As far as I can tell from the spec, dragstart and dragend use the same node
as the target, but it's not always the same node in Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D215827
Canvas uses CSS pixels, so this patch encodes the information into the type
system. Some painting code still uses unknown sizes, so we need to use
`CSSIntSize::FromUnknownSize` and `ToUnknownSize()` to convert them.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D216463
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
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
MaybeEditorDeletedSourceNode was defined on nsIDragService but is more appropriately defined on nsIDragSession. This was not an issue previously since those were the same object.
Differential Revision: https://phabricator.services.mozilla.com/D211074
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
We will need this to get the correct drag session in content when there are
multiple choices, and as a sanity check elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D215033
Introduces MockDragService as a subclass/implementation of nsBaseDragService.
This class is based on the Windows implementation of nsBaseDragService. The
service is created with a MockDragServiceController that JS can use to
initiate drag events that would normally come from the system. Native
drag-and-drop is not permitted in automation because it puts the browser into
a state where, if anything goes wrong (e.g. a test failure), it cannot be
killed without manual intervention. This allows us to avoid that limitation
while still testing most of the browser's drag-and-drop behavior, including
the (substantial and complex) nsBaseDragService base-class that is common to
all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D205640
PresShell doesn't do anything different if it gets called with
FlushType::Display vs FlushType::Layout. It should be fine to just pass
FlushType::Layout where appropriate and remove the redundant check.
Differential Revision: https://phabricator.services.mozilla.com/D210274
The dropped item is set on drop event handler in Android. Current
Gecko's implementation caches dropped item as `DataTransfer` when any
drag events are fired. It will works on desktop platform, but doesn't
on GeckoView. Even if drop item is set by handling drop event,
`DataTransfer`'s cache isn't refreshed.
So if drop event is received, we re-fill DataTransfer on GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D197331
Main thread and APZ controller thread are different on GeckoView. Some
drag events cannot be converted to InputData and aren't handled by APZ.
So we need consider drag events more for GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D197329
This allows us to deprecate `mozInputSource` for the Web while
avoiding console warnings for internal uses, which now use the
ChromeOnly `inputSource` attribute.
Differential Revision: https://phabricator.services.mozilla.com/D183643
Make all UA widgets also NAC.
Keep the UA widget flag but break at anonymous subtree boundaries, so
that only nodes inside the UA widget directly (and not NAC from those)
get the flag.
This is important because two callers depend on this difference:
* The style system, since we still want to match content rules from
stylesheets in the UA widget. We also match user rules, which is a
bit sketchy, but that was the previous behavior, will file a
follow-up for that.
* The reflector code, since we want the scope for UA widgets to not
include the NAC nodes inside that UA widget. nsINode::IsInUAWidget
got it wrong.
After this patch, ChromeOnlyAccess is equivalent to
IsInNativeAnonymousSubtree, so we should probably unify the naming.
That's left for a follow-up patch because I don't have a strong
preference.
Differential Revision: https://phabricator.services.mozilla.com/D174310
The source node is typically a text node, and it may be editable by
`contenteditable` or `designMode`. In that case, the source node may be removed
during the DnD session even without tricky JS code. In this case, Blink and
WebKit updates the source node to dispatch `dragend` to the editing host.
This behavior does not conform to the standardized DnD behavior, however,
this is reasonable for editor apps which want to listen to events in editing
host or window/document for footprint and/or performance reason. Therefore,
we should follow their behavior.
Differential Revision: https://phabricator.services.mozilla.com/D172091
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
All its members are optional, so we can just use it as a plain struct
rather than Maybe<> all around, which simplifies the code and prevents
silly bugs like bug 1779592.
Mostly automatic via:
rg -l 'SVGImageContext' . | xargs sed -i 's/Maybe<SVGImageContext>/SVGImageContext/g'
With trivial build fixes.
Not intended to change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D151846
The existing code was relying on the drag event coordinates being
already unscaled by the zoom, which bug 1753836 fixed.
This simplifies the relevant code and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D145578
Bug 1756241 changed nsDragService::mDragEndPoint to be relative to the
window. I didn't realize, but that point is passed as-is to child
widgets. Changing the widget event to actually have a widget made the
point be interpreted as widget-relative (which is correct in the parent
process, but not in the child process). Account for this and fix the
mDragEndPoint documentation while at it.
Differential Revision: https://phabricator.services.mozilla.com/D145182
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
When `nsTextControlFrame` is reframed, `TextEditor`, anonymous `<div>`, its
`Text` and the independent `Selection`s are deleted temporarily and recreated
them.
If users are dragging text in `<input>` or `<textarea>`, the drag session's
source node is set to the anonymous text node in the element and the selection
is set to the independent selection. So, if the element is reframed during a
drag, the source node is disconnected from the document and `EndDragSession`
failed to dispatch `eDragEnd` event.
Therefore, this patch makes `nsTextControlFrame` replaces the source node and
selection when it's recreated and only when the drag session's original source
node was in the text control element. For checking which text control had the
anonymous text node, this patch makes `nsTextControlFrame` replaces source
node with the `<input>` or `<textarea>` element when the frame is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D119487
I'm not sure whether we should deal with ancestor scales and such. There
seemed to be a discussion about that in D77436 but dealing with
partially-3d-transformed content sounds like a massive pain. For now
this fixes the start point, which is a progression.
Differential Revision: https://phabricator.services.mozilla.com/D106896
Sean Feng