Before inserting drag and drop content, corresponding editing host or text control element should be focused
Categories
(Core :: DOM: Editor, defect, P2)
Tracking
()
People
(Reporter: masayuki, Assigned: masayuki)
References
Details
Attachments
(3 files)
Currently, EditorBase::FireInputEvent()
computes input
event target from focused content. However, when dropping content, it's wrong and fails to dispatch input
event since drop target's editing host may not have focus yet. This causes beforeinput
event dispatcher fails to dispatch and it makes the drop event handler fails before handling the drop. Therefore, we need to fix this bug before implementing beforeinput
event.
This todo_is
must be caused by this bug:
https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/editor/libeditor/tests/test_dragdrop.html#260-261
Assignee | ||
Comment 1•5 years ago
|
||
Probably, my investigation was wrong. According to Chrome's behavior, they move focus to corresponding editing host or text control element which are parent of dropped point. If we do so, HTMLEditor
can handle inserting dropped content with same path as usual edit action handling.
However, the fix does not fix the todo_is
in comment 0. So, I still need to investigate this issue more.
Assignee | ||
Comment 2•5 years ago
|
||
Currently, any default drop effect is "move" on editable content even when
the editor cannot remove the source element (e.g., outside of any editing host).
The drop effect is initialized by nsContentUtils::SetDataTransferInEvent()
which is called when EditorEventListener::CanDrop()
and it returns true.
However, it requires unnecessary cost if we make nsContentUtils
check
whether the dragging element is removable. Therefore, we should make
EditorEventListener
overwrites it with checking whether the source node is
editable or not.
Assignee | ||
Comment 3•5 years ago
|
||
Chrome moves focus to dropped element or editing host containing dropped
element, but we don't do it. For compatibility with Chrome, it's better to
follow their behavior. Additionally, this fixes 2 issues. One is, when
dropping something into non-focused contenteditable element, we've failed to
initialize selection from TextEditor::PrepareToInsertContent()
because
pointToInsert
is outside of selection limiter if another editing host
has focus. The other is, when same case, we've failed to insert dropped
content because edit action handlers of HTMLEditor
check whether editing
position is in active editing host.
Finally, this patch makes TextEditor::OnDrop()
cancels to dispatch "input"
event if it fails something before trying to insert dropped content. Without
this change, EditorBase::DispatchInputEvent()
tries to dispatch without
proper data
or dataTransfer
and that hits MOZ_ASSERT
in nsContentUtils
.
Additionally, this fixes an existing bug which HTMLEditor
may insert \r
as-is if it comes from paste or drop. Otherwise, we need complicated todo_is
paths in test_dragdrop.html
.
Depends on D57446
Assignee | ||
Comment 4•5 years ago
|
||
User can move DnD between different 2 editors. Then, deleting selection in
drag source editor should be handled by the drag source editor rather than
drop target editor. Therefore, TextEditor::OnDrop()
should look for
editor instance for drag source node and call is "deleteByDrag" handler.
Depends on D57447
Comment 6•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ee54a01461e2
https://hg.mozilla.org/mozilla-central/rev/7857cb4a4c46
https://hg.mozilla.org/mozilla-central/rev/f2637cbcc2ca
Updated•5 years ago
|
Updated•5 years ago
|
Comment 8•5 years ago
|
||
I've reproduced this issue with Fx 72.0a1 (2019-11-02) on Windows 10.
The issue is verified fixed with Fx 73.0b12 and Fx 74.0a1 (2020-01-30) on Windows 10, Ubuntu 18.04 and macOS 10.15.
Description
•