The style editing commands should be disabled in
`contenteditable="plaintext-only"`. Currently, we return `false` from
`execCommand`, but we still claim that the commands are enabled for
`queryCommandEnabled`.
Differential Revision: https://phabricator.services.mozilla.com/D239985
This handles a race condition so if the user copies new data to the clipboard
while Content Analysis is ongoing, the original data will be used in the
paste action.
Differential Revision: https://phabricator.services.mozilla.com/D228719
This handles a race condition so if the user copies new data to the clipboard
while Content Analysis is ongoing, the original data will be used in the
paste action.
Differential Revision: https://phabricator.services.mozilla.com/D228719
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
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
If a `paste` event listener moves focus, Chrome makes new editor keep handling
the pasting. For the compatibility, we should follow it unless the new focused
element is in different document because user should allow to paste it
explicitly.
On the other hand, this just stops handling "cut" in same situation because
handling it requires to update clipboard without user's activation. Therefore,
the clipboard content and/or the new editor content may be lost from the users
point of view.
Note that `nsContentUtils::GetActiveEditor` may return `HTMLEditor` instance
when focused element does not have `TextEditor` even when non-editable element
has focus. Therefore, if it returns an `HTMLEditor`, we need to check whether
it's active in the DOM window with a call of `HTMEditor::IsActiveInDOMWindow`.
Differential Revision: https://phabricator.services.mozilla.com/D176741
If a `paste` event listener moves focus, Chrome makes new editor keep handling
the pasting. For the compatibility, we should follow it unless the new focused
element is in different document because user should allow to paste it
explicitly.
On the other hand, this just stops handling "cut" in same situation because
handling it requires to update clipboard without user's activation. Therefore,
the clipboard content and/or the new editor content may be lost from the users
point of view.
Note that `nsContentUtils::GetActiveEditor` may return `HTMLEditor` instance
when focused element does not have `TextEditor` even when non-editable element
has focus. Therefore, if it returns an `HTMLEditor`, we need to check whether
it's active in the DOM window with a call of `HTMEditor::IsActiveInDOMWindow`.
Differential Revision: https://phabricator.services.mozilla.com/D176741
It's always a pointer to `nsStaticAtom` instance or `nullptr`. Therefore,
it can be `nsStaticAtom*` and we can make its users treat `nsStaticAtom`
instead of `nsAtom`.
Additionally, this patch changes some pointer parameters to references if
they are never `nullptr`.
Differential Revision: https://phabricator.services.mozilla.com/D155310
For consistency with the similar internal DOM API, `As*()` should just cast
the type without checking editor type. Instead, `GetAs*()` should do it.
Differential Revision: https://phabricator.services.mozilla.com/D117381
`TextEditor` will be not a parent class of `HTMLEditor`. Therefore, editor
command classes should use `EditorBase` class instead.
Depends on D117116
Differential Revision: https://phabricator.services.mozilla.com/D117117
When it refers computed value of style, it may flush pending notifications.
Therefore, they should be marked as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D70151
When it refers computed value of style, it may flush pending notifications.
Therefore, they should be marked as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D70151
`AlignStateAtSelection` class is instantiated outside of editor class so that
we shouldn't make each user guarantee that there is selection range
(fortunately, the putting off cost is really low).
And as far as I tested, Blink and WebKit does not throw exception when
`Document.qeuryCommand*("justify*")` is called without selection ranges.
So, this patch also prevents exception in this situation.
Differential Revision: https://phabricator.services.mozilla.com/D68755
Some HTML editor command classes call `*AsAction()` methods multiple times.
That causes that user needs multiple undo/redo for a command and one command
causes multiple "input" events. For both compatibility with the other
browsers and making "beforeinput" cancelable, they should call `*AsAction()`
once. Instead, `HTMLEditor` should handle related element deletion.
This patch makes `HTMLEditor::RemoveInlinePropertyInternal()` remove multiple
elements if its caller allows, and `HTMLEditor::SetInlinePropertyAsAction()`
call `RemoveInlinePropertyInternal()` in some cases.
According to comm-central and BlueGriffon, we can make
`HTMLEditor::RemoveInlineProperty()` also removes the related methods
automatically because comm-central does same thing from script and BlueGriffon
does not use this. However, we cannot do that for
`HTMLEditor::SetInlineProperty()` because BlueGriffon may call it with any
HTML5 elements and does not expect removing elements in same block at that
time. If we needed to reduce the overhead of comm-central, we could change
only `RemoveInlineProperty()`, but it would make these APIs behavior
inconsistent.
Differential Revision: https://phabricator.services.mozilla.com/D58124
Some HTML editor command classes call `*AsAction()` methods multiple times.
That causes that user needs multiple undo/redo for a command and one command
causes multiple "input" events. For both compatibility with the other
browsers and making "beforeinput" cancelable, they should call `*AsAction()`
once. Instead, `HTMLEditor` should handle related element deletion.
This patch makes `HTMLEditor::RemoveInlinePropertyInternal()` remove multiple
elements if its caller allows, and `HTMLEditor::SetInlinePropertyAsAction()`
call `RemoveInlinePropertyInternal()` in some cases.
According to comm-central and BlueGriffon, we can make
`HTMLEditor::RemoveInlineProperty()` also removes the related methods
automatically because comm-central does same thing from script and BlueGriffon
does not use this. However, we cannot do that for
`HTMLEditor::SetInlineProperty()` because BlueGriffon may call it with any
HTML5 elements and does not expect removing elements in same block at that
time. If we needed to reduce the overhead of comm-central, we could change
only `RemoveInlineProperty()`, but it would make these APIs behavior
inconsistent.
Differential Revision: https://phabricator.services.mozilla.com/D58124
For compatibility with Chrome, when removing inline style at block parent,
we should reset the style with creating `<span>` element whose `style`
attribute removes the style. We do this only in CSS mode, but we should do
it in HTML mode too.
This patch also makes `FontFaceStateCommand::SetState()` ignore `tt` value
if its root caller is `Document::ExecCommand()`. It was implemented for
composer to handle XUL command in bug 115922. Therefore, we should not do
this special handling on the web. If it were possible to separate this
change to another bug, it'd be nicer. But without this change, we'll have
a lot of regressions of `Document.execCommand("fontname")`. Therefore,
this is also fixed in this patch.
Note that this removes first `.ini` file selection because
the tests cannot be run without test number range parameter.
So, the sections are not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D47862
For compatibility with Chrome, when removing inline style at block parent,
we should reset the style with creating `<span>` element whose `style`
attribute removes the style. We do this only in CSS mode, but we should do
it in HTML mode too.
This patch also makes `FontFaceStateCommand::SetState()` ignore `tt` value
if its root caller is `Document::ExecCommand()`. It was implemented for
composer to handle XUL command in bug 115922. Therefore, we should not do
this special handling on the web. If it were possible to separate this
change to another bug, it'd be nicer. But without this change, we'll have
a lot of regressions of `Document.execCommand("fontname")`. Therefore,
this is also fixed in this patch.
Note that this removes first `.ini` file selection because
the tests cannot be run without test number range parameter.
So, the sections are not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D47862
It takes a lot of `bool` out arguments. Therefore, we should make it a
stack only class and caller should retrieve only necessary information.
Differential Revision: https://phabricator.services.mozilla.com/D45787
`HTMLEditRules::WillMakeDefinitionList()` just calls
`HTMLEditRules::WillMakeList()` and `HTMLEditRules::WillMakeList()` can be
called as `HTMLEditRules::MakeOrChangeListAndListItemAsSubAction()` so that
we should merge them and make `HTMLEditor` call it directly.
This patch also removes default action part of
`HTMLEditor::MakeOrChangeListAsAction()` because it runs only when
`HTMLEditRules::WillDoAction()` does not return canceled nor error but not
handled, however, it's won't occur since `HTMLEditRules::WillMakeList()`
always sets `aHandled` to `true` when it returns `NS_OK`.
Differential Revision: https://phabricator.services.mozilla.com/D44195
`Document::ExecCommand()` knows subject principal. This patch makes it tell
`EditorCommand::DoCommand()` and `EditorCommand::DoCommandParam()`. Then,
makes they tell each editor public methods which may cause dispatching
`beforeinput` event once we implement it. Finally, each editor public
method sets it to the constructor of `EditorBase::AutoEditActionDataSetter`.
This means that when editor tries to dispatch `beforeinput` event, editor
can check whether it's called by JS or not from everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D29635
`cmd_align` is always with `nsCommandParams` when it's executed. However,
when somebody checks whether the command is enabled or not, or retrieves the
state, `GetInternalCommand()` is called without `nsCommandParams`. Therefore,
even when `nsCommandParmas` is nullptr for `cmd_align`, `GetInternalCommand()`
shouldn't warn it.
Additionally, internal command supports to set `align` to empty string.
Therefore, `GetInternalCommand()` also needs to support it.
This patch adds `Command::FormatJustify` for the former case and
`Command::FormatJustifyNone` for the latter case.
Note that this does not affect to actual behavior since `AlignCommand`
does not refer the result of `GetInternalCommand()`.
Differential Revision: https://phabricator.services.mozilla.com/D33604
Only `MultiStateCommandBase::DoCommandParams()` allows `CString` param and
`String` param (the former is preferred). This patch makes
`EditorCommand::DoCommandParams()` aware of this case.
Differential Revision: https://phabricator.services.mozilla.com/D30499
If `nsIControllerCommand::DoCommandParams()` is called with `nullptr` for its
`aParams`, this patch sets `VoidString()` to `DoCommandParam()` for making
each implementation be able to consider whether the case is an error or
treat it as specific default value.
Differential Revision: https://phabricator.services.mozilla.com/D30498
Most `EditorCommand` classes don't require additional params for executing
a command. All of them just calls their `DoCommand()` or returns same result.
So, we can create new virtual method,
`EditorCommand::DoCommandParam(Command aCommand, TextEditor& aTextEditor)`,
which just delegates to `DoCommand()`.
This patch adds some undeclared commands but which are handled by
`EditorCommand` subclasses, and changes `CommandInt` type from `int8_t` to
`uint8_t` since the count of `Command` items becomes over 128.
Differential Revision: https://phabricator.services.mozilla.com/D30495
Currently, this bug does not occur actually because nobody has not accessed
these command classes directly and they are registered only in command table
for HTML editor. However, once rewriting `nsHTMLDocument::ExecCommand()` with
these classes, its `IsCommandEnabled()` should return false if given editor
is `TextEditor`. The reason why we need this fix is, when we make
`ExecCommand()` call `IsCommandEnabled()` and it returns `true`, `ExecCommand()`
needs to call `DoCommand()`. Then, it throws exception if given editor is not
an `HTMLEditor` but the command class is only for `HTMLEditor`.
This patch adds new WPT for testing whether `document.execCommand()` works
with `<input>` and `<textarea>`. The behavior has not been standardized, but
Chromium handles some commands even in it. So, I write the expectations from
the point of view of web developers. (Chrome fails in "cut", "copy" and
"removeformat" cases.)
Differential Revision: https://phabricator.services.mozilla.com/D29473
`strcmp` may be slow due to checking null character. Therefore, internal
methods of them should use command as far as possible. This patch makes
them take/use `Command` instead of `const char*`.
Differential Revision: https://phabricator.services.mozilla.com/D29174
Now, all callers of `GetCurrentState()` have reference or pointer to
`nsCommandParam`. So, taking the concrete class makes sense.
Differential Revision: https://phabricator.services.mozilla.com/D28697
This patch makes `EditorCommand` implement
`nsIControllerCommand::GetCommandStateParams()` and then, makes it call internal
`GetCommandStateParams()` method which takes `TextEditor` or `nsIEditingSession`
instead.
This makes each implementation really simpler.
Differential Revision: https://phabricator.services.mozilla.com/D28696
This patch makes `EditorCommand` implement
`nsIControllerCommand::DoCommandParams()` and then, makes it call internal
`DoCommandParams()` method which takes `TextEditor` instead.
This makes each implementation really simpler.
Differential Revision: https://phabricator.services.mozilla.com/D28694
This patch makes `EditorCommand` implement `nsIControllerCommand::DoCommand()`
and then, makes it call internal `DoCommand()` method which takes `TextEditor`
instead.
Note that `DoCommand()` of some command classes have not returned error when
given context is not editor. However, it does not make sense to do that only
for some commands. Therefore, this patch makes `EditorCommand::DoCommand()`
return error when given context is not an editor.
This makes each implementation really simpler.
Differential Revision: https://phabricator.services.mozilla.com/D28691
Daniel Holbert