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
Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/ee54a01461e2 part 1: Make `EditorEventListener` handle `dropEffect` r=m_kato https://hg.mozilla.org/integration/autoland/rev/7857cb4a4c46 part 2: Make `TextEditor::OnDrop()` move focus before inserting dropped content r=m_kato https://hg.mozilla.org/integration/autoland/rev/f2637cbcc2ca part 3: Make `TextEditor::OnDrop()` use another editor which is drag source editor to remove selection r=m_kato
|
||
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
•