As far as I've tested, `<br>` element is always treated as usual even if its
`display` is set to anything except `none`. Therefore, preceding collapsible
white-spaces and `<br>` element should be treated as visible even if the
following `<br>` element is `display:block` or something.
Note that if `display:none` is specified, we should not treat it as a line
break, but our editor cannot work properly in the case and `HTMLEditUtils`
currently uses the default style of HTML elements if `display:none` is
specified. Therefore, this patch makes `HTMLEditUtils` always treat `<br>`
as inline.
Differential Revision: https://phabricator.services.mozilla.com/D203403
This simplifies our combobox code a bit more:
* Reflow() is only needed to compute the label isize.
* Frame construction uses a setup more similar to <input type=file> to
get the right frame tree, removing a bunch of special code.
* Lots of special code removed all over the place.
Differential Revision: https://phabricator.services.mozilla.com/D203010
It's currently handling its job with the closest ancestor block which may be
non-editable and editing host which is either inline or block. However, the
closest block is required for check whether the range won't be extended outside
the closest block of the common ancestor of the range and the range is
guaranteed that they are in an editing host. Therefore, it's not required if
it's outside the editing host. So, comparisons which check whether a node is
either/neither editing host or/nor ancestor block can get same result with
comparing with the closest one of the editing host or the closest editable
block.
Differential Revision: https://phabricator.services.mozilla.com/D202697
When focused element becomes editable by `contentedtiable=true`, IME
content observer isn't created on some situations. Then IME focus isn't
set.
At first, when focused element becomes non-editable,
`FocusedElementOrDocumentBecomesNotEditable` will destroy IME content
observer, but editor might not be destroyed completely since HTML content
has multiple `contenteditable` and has focus.
Then, when focused element becomes editable again,
`FocusedElementOrDocumentBecomesEditable` will check selection ancestor
limit, but since editor isn't destroyed by previous `contenteditable`
change, we already have this limit. Then we don't create IME content
observer.
So we should set current IME state and create IME content observer when
becoming editable.
Differential Revision: https://phabricator.services.mozilla.com/D202409
It checks whether the document body itself is empty or not. However, if there
is only a shadow DOM hosts, it considers the content is empty. Therefore,
`HTMLEditor::HandleDeleteSelection` does nothing.
I think that it should check whether current editing host is empty or not.
That does not work without selection ranges, but I think it's fine in most
cases.
Differential Revision: https://phabricator.services.mozilla.com/D202274
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
In bug 1851951, I considered that the method should keep the traditional
behavior for the backward compatibility because of mainly used by handling
a block level command, `formatBlock`, but I think that computing the replacing
part should be considered with the computed style of the elements. That's
compatible with the other browsers.
Depends on D199844
Differential Revision: https://phabricator.services.mozilla.com/D199845
GeckoView's drag threshold is large and mochitest runs on mobile
viewport.
So I would like to adjust this value to run drag and drop tests on
GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D197332
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
The default value of `<textarea>` may be changed during reframes of the
corresponding `nsTextControlFrame`. Then, the `TextEditor` and the anonymous
subtree is recreated. In this moment, `IMEContentObserver` will restart to
observer the anonymous subtree after the editor is completely initialized,
but new default value which is caused by a mutation under `<textarea>` is
copied at recreating the anonymous subtree. Therefore, `IMEContentObserver`
fails to notify the text change before a further selection change.
For solving this issue, this patch makes `TextControlState` notifies
`IMEContentObserver` of default value change at recreating a new `TextEditor`.
Therefore, this patch may cause redundant text change notifications for IME.
Currently, I have a plan to fix bug 854272 to carry `TextEditor` instance and
the anonymous subtree over to new `nsTextControlFrame`. So, I believe that
this approach is reasonable for now (It'd be easier if we could add new
`nsString` to `TextControlState` without increasing the instance size, though).
Differential Revision: https://phabricator.services.mozilla.com/D197261
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
If given `nsPresContext` is for a lazy loading `<iframe>` and the frame has not
been loaded yet, its `GetTextInputHandlingWidget()` may return `nullptr`.
However, `IMEStateManager::sTextInputHandlingWidget` may have already cache it.
Therefore, `IMEStateManager` should use:
* `sTextInputHandlingWidget` if it's available
* otherwise, `nsPresContext::GetTextInputHandlingWidget()`
Differential Revision: https://phabricator.services.mozilla.com/D197991
The method does not assume that an inline ancestor is not a splittable, but
it may occur in the edge cases.
I tried to make `HTMLEditor` adjust selection range at starting deletion to
stop handling it or select the most distant unmodifiable element, but it
requires some expectation changes of tentative WPTs. It should be done in
a separate bug instead.
Differential Revision: https://phabricator.services.mozilla.com/D198345
`beforeinput` event shouldn't be fired if it's caused by JS. However, we
dispatch it when the call is by chrome script or an addon because there is
no user input emulation API for WebExtension and builtin editors make the
change undoable only when JS changes the editor value with
`Document.execCommand`. Therefore, addons may want to use
`Document.execCommand` for making the change undoable.
On the other hand, nested calls of `Document.execCommand` makes the error
handlings in editor classes too complicated. Therefore, we don't allow that.
However, this causes that if web apps intercept `beforeinput` events and
prevents the default and calls `document.execCommand`, the first call of
web apps may be first nested call if the `beforeinput` event is caused by
a call of `Document.execCommand` in addon.
Therefore, this patch makes `Document` stores whether `ExecCommand` is called
by content or chrome/addon. And if the call is improperly nested, keep stopping
handling the command, but allows if and only if the first call is by
chrome/addon.
Differential Revision: https://phabricator.services.mozilla.com/D198357
The test case removes entire the `<output>` during deleting its content and
that occurs during it moves the content in `<div>` into the preceding `<ruby>`.
Therefore, the destination becomes not connected to the document so that it
fails to track the range of moved contents in the document.
Then, the code does not explicitly mark the caret position is not necessary.
So, we just need to do it.
Differential Revision: https://phabricator.services.mozilla.com/D198148
Invalid children of `<picture>` like text may appear as usual. Therefore,
they should be editable.
Note that this patch does not fix the root cause of the assertion because
if selection range may cross a remaining element boundary listed in the
method, but I couldn't find a way to fix this with a reasonable size patch.
Differential Revision: https://phabricator.services.mozilla.com/D197988
Oddly, it returns the latest result as split result. However, in the case,
it splits `<kbd>` under `<button>`, but does not split `<button>`, but the
caller expects that whether it did split or not.
Differential Revision: https://phabricator.services.mozilla.com/D197262
It treats non-editable content as invisible. Therefore, if you try to
delete backward/forward from first/last block, Gecko deletes the block with
the non-editable content.
Depends on D196817
Differential Revision: https://phabricator.services.mozilla.com/D196819
Pasting and inserting HTML clears current style to respect the new style.
Therefore, the old ancestors shouldn't be removed when they have only
non-editable content.
Unfortunately, I have no idea how to test all of the paths which are changed
by this patch. However, I believe the method should always treat non-editable
content as visible.
Differential Revision: https://phabricator.services.mozilla.com/D196817
If the parent block has only non-editable, it treat the block as invisible and
puts `<br>`. Therefore, deleting content may cause inserting new line in some
cases.
Depends on D196814
Differential Revision: https://phabricator.services.mozilla.com/D196815
When it cleans up unnecessary new empty inline ancestors, it should treat
non-editable elements in the inline containers as visible.
Depends on D196813
Differential Revision: https://phabricator.services.mozilla.com/D196814
It means that "treat non-editable things as visible" when it's not set.
However, it's odd. You must assume that if no option is set, `IsEmpty()` etc
should treat non-editable nodes as visible things. Therefore, this renames it
to `TreatNonEditableContentAsVisible` and changing all callers of
`HTMLEditUtils::IsEmptyNode`, `HTMLEditUtils::IsEmptyInlineContainer`,
`HTMLEditUtils::IsEmptyBlockElement` and
`HTMLEditUtils::CollectEmptyInlineContainerDescendants`. So, this does not
change any behavior.
Differential Revision: https://phabricator.services.mozilla.com/D196813
It allows multiple edit action preserves `Selection` when updating the DOM tree.
However, most callers do not use `finally` to reset the state, and this makes
edit action handling complicated in some edge cases. Therefore, let's stop
supporting this feature. If Thunderbird requires the feature, the developers
should request additional param for preserving `Selection` like the preceding
patch.
Depends on D196004
Differential Revision: https://phabricator.services.mozilla.com/D196005
`nsIEditor.setShouldTxnSetSelection` can preserve selection across multiple
editing. Therefore, we cannot manage the state only in the stack.
It's used only in comm-central, and used only with `insertNode` and
`deleteNode`. Therefore, adding new param to them to preserve selection
must be enough.
While I'm writing this patch, I realized that `input` event is not fired
by these methods because nobody set a placeholder transaction. That may
lead Thunderbird only IME crash bugs due to `IMEContentObserver` is not
notified editor properly. Therefore, this may fix some Thunderbird only
crashes.
Note that `deleteNode` should not update selection. However, I'm not 100%
sure that. Therefore, I add new param to `deleteNode` too. However,
some reviewers think it's unnecessary, I'll remove it before landing.
Finally, `beforeinput` and `input` caused by the method calls start updating
selection. However, I think that it should be better behavior. If Thunderbird
needs to guarantee that selection is set to whether the user expected when
it calls these methods with preserving selection.
Differential Revision: https://phabricator.services.mozilla.com/D196004
Masayuki Nakano
Gregory Pappas
Dave Townsend
Iulian Moraru
Emilio Cobos Álvarez
Makoto Kato
Joel Maher
Greg Stoll
Cristian Tuns
Tom Schuster
Tom Marble
Sandor Molnar
Jonathan Kew
Stanca Serban
Narcis Beleuzu
Tooru Fujisawa
Jeff Muizelaar