`while (RefPtr<Attr> attr = attributes->Item(0))` causes a warning in
`nsDOMAttributeMap::IndexedGetter()` because of out of bounds. Additionally,
we should not make a loop with live DOM tree information if the loop updates
the DOM tree. Therefore, this patch makes it collect all attributes first
before touching the DOM tree.
Depends on D207240
Differential Revision: https://phabricator.services.mozilla.com/D207241
Sorry for the massive patch but I found it hard to split without
introducing a bunch of copies around...
This mostly makes necko and DOM agree on which strings to use, which
should result on less copies and conversions.
Differential Revision: https://phabricator.services.mozilla.com/D205601
Although from the maintenance cost point of view, we should not duplicate
`EditorBase::DeleteRangesWithTransaction`, but let's add a wrapper for it
for making the callers simpler.
Differential Revision: https://phabricator.services.mozilla.com/D203854
It and its helper class, `AutoInclusiveAncestorBlockElementsJoiner` work with
multiple ranges, but they handle special cases only with the first range.
That means that deleting content will be different if same structure is selected
with multiple ranges and that must be not expected by the users.
Differential Revision: https://phabricator.services.mozilla.com/D203853
The purpose of this patch is to prevent users to make changes to
read-only editors.
This patch forces `IsCommandEnabled()` to return false for read-only
editors for "standard" editor commands that could have an associated
icon or menu entry and are therefore user-accessible.
This patch does not modify/test any paste commands or any of the
advanced internal editor commands.
Differential Revision: https://phabricator.services.mozilla.com/D203754
The purpose of this patch is to prevent users to make changes to
read-only editors.
This patch forces `IsCommandEnabled()` to return false for read-only
editors for "standard" editor commands that could have an associated
icon or menu entry and are therefore user-accessible.
Advanced internal editor commands are not touched.
Differential Revision: https://phabricator.services.mozilla.com/D203754
When copying paragraphs in Gecko, some private type data is copied into the
clipboard and our editor refers the private data at pasting such data. In
this case, `text/_moz_htmlinfo` has 2 integers to specify the range at the
copy. If selection range ends at end of text followed by an invisible `<br>`
and a block boundary, this is set to the depth of the text node. Then,
`HTMLWithContextInserter::CollectTopMostChildContentsCompletelyInRange` collects
top most children of the last paragraph in `HTMLWithContextInserter::Run` [1].
Therefore, the last `<div>` in the clipboard is unwrapped at pasting in the
test case. This patch makes
`FragmentFromPasteCreator::MoveStartAndEndAccordingToHTMLInfo` re-climb up the
tree under the common ancestor of found start/last nodes.
1. https://searchfox.org/mozilla-central/rev/6b1e306175c2284958fb185bab388021e2890ed0/editor/libeditor/HTMLEditorDataTransfer.cpp#646-651
Differential Revision: https://phabricator.services.mozilla.com/D203574
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
