Open
Bug 1413131
Opened 7 years ago
Updated 2 years ago
HTMLEditor::GetActiveEditingHost() should return any elements (even if outside `<body>`), but return `<body>` element if selection is in `<body>` and actual editing host is a parent of it
Categories
(Core :: DOM: Editor, defect, P3)
Core
DOM: Editor
Tracking
()
NEW
People
(Reporter: masayuki, Unassigned)
References
(Blocks 5 open bugs)
Details
IIRC, older HTML5 spec declared that editing host of a document whose designMode is "on" is its <body>. However, currently, it's declared as: > An editing host is a node that is either an HTML element with a > contenteditable attribute set to the true state, or the HTML element child > of a document whose designMode is enabled. in the execCommand spec: https://w3c.github.io/editing/execCommand.html#editing-host which is referred by https://html.spec.whatwg.org/multipage/interaction.html#best-practices-for-in-page-editors Additionally, current our behavior doesn't allow to edit something outside the <body> element. E.g., you cannot type characters in the second box which is a <div>, next sibling of the <body>. https://jsfiddle.net/d_toybox/Lzwuk73j/ So, I think that we should change our behavior.
Updated•7 years ago
|
Priority: -- → P3
Reporter | ||
Comment 1•4 years ago
|
||
Resetting assignee which I don't work on in this several months.
Assignee: masayuki → nobody
Reporter | ||
Comment 2•2 years ago
|
||
It has some issues:
- It does not support outside
<body>
indesignMode
- It returns editing host for the focus node/offset of
Selection
, but many its users refer first selection range, so actual editing host may be different nsIContent::GetEditingHost
does not stop scanning parents when it reaches<body>
and this makesGetActiveEditingHost
complicated
I think that if scanning start position is in the <body>
of the composed document, they should return <body>
even if its parent <html>
is editable. That's different from the spec definition, but in most cases, it must be reasonable.
And I think that EditorBase
should have a method to get "primary selection range" which is switchable with a new pref. Then, GetActiveEditingHost
and its users should use it. Then, we can fix various edge cases such as reported as hitting assertions.
Finally, the core implementation should be in EditorDOMPointBase
rather than HTMLEditor
. HTMLEditor::GetActiveEditingHost
should be a user of it.
Severity: normal → S3
Type: enhancement → defect
status-firefox58:
affected → ---
No longer depends on: 1697989
Reporter | ||
Updated•2 years ago
|
Summary: HTMLEditor::GetActiveEditingHost() should return document element rather than <body> if document.designMode is "on" → HTMLEditor::GetActiveEditingHost() should return any elements (even if outside `<body>`), but return `<body>` element if selection is in `<body>` and actual editing host is a parent of it
Reporter | ||
Updated•2 years ago
|
Alias: editing-outside-body
Reporter | ||
Updated•2 years ago
|
Alias: editing-outside-body
You need to log in
before you can comment on or make changes to this bug.
Description
•