It treats some inline elements as contextual elements. Then, they will be
preserved in copied HTML fragment. However, if an inline element is an editing
host, we don't want to contain it to the copied fragment because pasting it
causes duplicating same style into same editing host. So, if the style includes
relative style like `font-size: 2em`, it will cause bigger text than the
surrounding text. Additionally, the inline editing host usually has a border
but we don't want to make it appear in editable text.
Unfortunately, with this change, we stop copying the text style specified to
the inline editing host. However, this is same behavior as when the editing
host is a block element like `<div>`. Note that pasted text will be merged into
the inline editing host style. Therefore, if and only if the destination has
different style from the editing host, the result might be different from the
expected one by the user. However, this is a long standing issue, see
bug 1428046, for example.
Differential Revision: https://phabricator.services.mozilla.com/D228623
Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
Currently `MoveNodeResult` inherits only `CaretPoint` and has some members which
are same as `EditActionResult`. I'd like to add `DeleteRangeResult` which will
inherit both `CaretPoint` and `EditActionResult`. So, for making it work with
`MoveNodeResult`, it's nicer to make `MoveNodeResult` inherits
`EditActionResult`.
Differential Revision: https://phabricator.services.mozilla.com/D228629
Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
The backed-out patch is Bug 1923251 (part 1).
This does not backout the changes in `EditorDOMPoint.h`, `WSRunObject.h` and
template method instantiation in `WSRunObject.cpp` to make some other my local
changes keep working. (They won't affect to any behavior.)
Depends on D226631
Differential Revision: https://phabricator.services.mozilla.com/D226632
The point may not be set if the selection move is prevented or not suggested.
Therefore, it should check the caret position before calling
`EnsureNoFollowingUnnecessaryLineBreak`. On the other hand,
`HandleDeleteCollapsedSelectionAtWhiteSpaces` should use `Selection` instead
if caret position is not suggested. It should be handled in bug 1925424.
Differential Revision: https://phabricator.services.mozilla.com/D226092
Unfortunately, the code does not work well only in `white-space: pre-line`.
The rending itself is broken, so, it won't work well on Firefox anyway and
this style is not so useful with editable content. Therefore, this patch
does not fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D225039
Both Chrome and Safari clean up unnecessary padding line breaks when they become
unnecessary. Therefore, we should follow that.
Differential Revision: https://phabricator.services.mozilla.com/D225038
Unfortunately, the code does not work well only in `white-space: pre-line`.
The rending itself is broken, so, it won't work well on Firefox anyway and
this style is not so useful with editable content. Therefore, this patch
does not fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D225039
Both Chrome and Safari clean up unnecessary padding line breaks when they become
unnecessary. Therefore, we should follow that.
Differential Revision: https://phabricator.services.mozilla.com/D225038
Chrome and Safari splits ancestors when `document.execCommand("insertImage")`
inserts an `<img>`, but we insert into the closest inline element. For example,
```html
<b>A[]B</b>
```
Chrome and Safari make it to:
```html
<b>A</b><img><b>B</b>
```
But Firefox makes it to:
```html
<b>A<img>B</b>
```
I think that we should not change the behavior on Thunderbird. Therefore, the
behavior is controlled with the new `options` argument and the new behavior
runs only when the `HTMLEditor` works for content document and it's not caused
by the XPCOM method.
Differential Revision: https://phabricator.services.mozilla.com/D225037
This patch makes `HTMLEditor::HandleInsertText` compute the editing host without
limiting in the `<body>` for consistency with the other edit action handlers
which we've changed at implementing `contenteditable=plaintext-only`.
Unfortunately, there are a lot of changes to pass the editing host to
`EnsureCaretNotAfterInvisibleBRElement()`, though.
Note that the tests trying to preserve the style in
`contenteditable=plaintext-only` fails on Chrome too due to `<br>` is put
outside the `<b>` or forgot the `<b>` after caret move. However, as you know,
`contenteditable=plaintext-only` does not allow to change text style even
for web app developers. Therefore, loosing the style only in some conditions
must be wrong. Therefore, I made the expectations.
Differential Revision: https://phabricator.services.mozilla.com/D224188
Selection ranges can cross editing host boundaries if no editing host has focus.
Therefore, `Selection.focusNode` may be in an editing host but there may be
no active/focused editing host.
The computation may be expensive if there are a lot of ranges and selecting
in slotted shadow tree. However, it's rare case, so, I think it's okay for
now.
Differential Revision: https://phabricator.services.mozilla.com/D224282
It was shipped in 123 and now in the ESR. We don't have regression report in
the wild. So, it must be fine to get rid of the pref.
Differential Revision: https://phabricator.services.mozilla.com/D224559
Chrome treats `Enter` key press as `insertLineBreak` instead of
`insertParagraph`. Additionally, Chrome handles `insertParagraph` command
work as same as when `contenteditable=true`. Therefore, `HTMLEditor` needs
to change the behavior at handling `eKeyPress` event.
Depends on D224184
Differential Revision: https://phabricator.services.mozilla.com/D224185
Before bug 1921705, the first `ArrowRight` key press moves caret to end of the
non-editable character "A". Therefore, nothing is changed by pressing `Enter`
nor `Backspace`. However, `beforeinput` events are fired due to bug 1921700.
In bug 1921705, we fix the caret move issue. Then, this test starts editing.
Therefore, `input` events should be fired as same as `beforeinput` events.
Additionally, due to the complicated collapsible white-space handling, some
results are not same as original text content. Therefore, we need to adjust
the expected results.
Depends on D224183
Differential Revision: https://phabricator.services.mozilla.com/D224184
Chrome sets `beforeinput.data` instead of `beforeinput.dataTransfer`, but
Input Events Level 2 spec defines that browsers should set `dataTransfer` when
**contenteditable** [1]. Therefore, the new WPT expects `dataTransfer`.
However, it's unclear that the `dataTransfer` should have `text/html` or only
`text/plain`. From web apps point of view, `text/html` data may make them
serialize the rich text format to plaintext without any dependencies of browsers
and OS. On the other hand, they cannot distinguish whether the user tries to
paste with or without formatting when `contenteditable=true`. Therefore, I
filed a spec issue for this. We need to be back later about this issue.
1. https://w3c.github.io/input-events/#overview
2. https://github.com/w3c/input-events/issues/162
Differential Revision: https://phabricator.services.mozilla.com/D223908
Unfortunately, (even tough we're the last implementor of this feature`,) there
are not editing behavior tests in web-platform tests. Therefore, this patch
creates new `plaintext-only` directory into `editing` and make the feature
enabled in its `__dir__.ini` to check the implementing behavior with new tests.
This patch also changes how to compute the editing host (whether using `<body>`
or not when selection is outside it), but the new behavior (not limited in the
`<body>`) should work fine in the most cases and I believe that it's better
than current implementation in some methods.
Note that Chrome considers whether the style should be updated or not with
the closest inclusive ancestor of the **focus node** of `Selection`. However,
it's odd and aligning to the behavior requires bigger change. Therefore, I'd
like to implement this feature only with checking the focused editing host.
Differential Revision: https://phabricator.services.mozilla.com/D223277
`aHTMLEditor` may be `nullptr` and there may have been an `HTMLEditor` before
it's called. Therefore, it may need to adjust IME state even if `aHTMLEditor`
is `nullptr`. So, it should adjust IME state from `aDocument` which should be
same as `aHTMLEditor->GetDocument()` if `aHTMLEditor` is not `nullptr`.
Note that if `IMEStateManager` thinks another `nsPresContext` has focus, it does
not touch IME state. Therefore, it's safe to skip checking the focus state of
the `Document`.
Differential Revision: https://phabricator.services.mozilla.com/D220772
