Open Bug 1413131 Opened 8 years ago Updated 1 year ago

`HTMLEditor::ComputeEditingHost()` 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)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

People

(Reporter: masayuki, Unassigned)

References

(Blocks 4 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.
Priority: -- → P3

Resetting assignee which I don't work on in this several months.

Assignee: masayuki → nobody

It has some issues:

  • It does not support outside <body> in designMode
  • 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 makes GetActiveEditingHost 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.

Blocks: 1697989, redesign-editor-module, editing-outside-body, 1728566, 1741494
Severity: normal → S3
Type: enhancement → defect
status-firefox58: affected → ---
No longer depends on: 1697989
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
Alias: editing-outside-body
Alias: editing-outside-body
Summary: 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 → `HTMLEditor::ComputeEditingHost()` 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
Duplicate of this bug: 115700
You need to log in before you can comment on or make changes to this bug.