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
Although these commands supported supported only by Gecko, we shouldn't stop
supporting them unless we know the usage in the wild. Therefore, this patch
adds the handling code for `TextEditor` too.
Differential Revision: https://phabricator.services.mozilla.com/D108571
Although these commands supported supported only by Gecko, we shouldn't stop
supporting them unless we know the usage in the wild. Therefore, this patch
adds the handling code for `TextEditor` too.
Differential Revision: https://phabricator.services.mozilla.com/D108571
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
For preparing to remove `nsIPlaintextEditor` interface, this patch moves
all of them to `nsIEditor`, but for avoiding bustage in comm-central, makes
`nsIPlaintextEditor` inherit `nsIEditor` for now (i.e., even with this patch,
script can access old `nsIPlaintextEditor` members with the interface.
In C++ code, this patch moves `SetWrapColumn()`, `InsertTextAsAction()`,
`InsertTextAsSubAction()` and `InsertLineBreakAsSubAction()` because
they do common things between `TextEditor` and `HTMLEditor`. On the other
hand, this does not move `TextEditor::GetTextLength()` because it's designed
only for `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D60820
--HG--
rename : editor/libeditor/tests/test_nsIPlaintextEditor_insertLineBreak.html => editor/libeditor/tests/test_nsIEditor_insertLineBreak.html
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
`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
--HG--
extra : moz-landing-system : lando
If `nsIControllerCommand::DoCommandParams()` is called with `nullptr` for its
`aParams`, this patch sets `VoidCString()` 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/D30497
--HG--
extra : moz-landing-system : lando
We should use `Maybe` for `bool` because some command may treat the default
value when the parameter is omitted as `true` or `false. Although, current
implementation does not do that.
Differential Revision: https://phabricator.services.mozilla.com/D30496
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
`nsIDocumentStateListener` is a scriptable interface and each method may run
any script. So, we should mark them as `can_run_script`. Then, we need to
mark a lot of editing methods because we need to mark
`EditorBase::EndTransactionInternal()` and `EditorBase::DoTransactionInternal()`
as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D30360
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
`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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This patch makes `EditorCommand` implement
`nsIControllerCommand::IsCommandEnabled()` and then, makes it call internal
`IsCommandEnabled()` method which returns `bool` directly and takes `TextEditor`
instead.
This makes each implementation really simpler.
Differential Revision: https://phabricator.services.mozilla.com/D28687
--HG--
extra : moz-landing-system : lando
When declaring a common base class of all editor command classes in
EditorCommands.h, we need to declare some useful macro to declare its
subclasses. However, such macro should be `#undef`ed in the header file.
Therefore, this patch moves all contents in HTMLEditorCommands.h to
EditorCommands.h and removes it from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D28682
--HG--
extra : moz-landing-system : lando
Some "HTML editor commands" are stateful due to storing tag name to handle it
with specific command. However, we can make it stateless with retrieving
tag name from command name once per command only when it's necessary. The
runtime cost must be really cheap since we can map it with hash table.
This patch makes them stateless and singleton classes. So, we can save
footprint and allocation runtime cost with this change.
Differential Revision: https://phabricator.services.mozilla.com/D27407
--HG--
extra : moz-landing-system : lando
`nsICommandManager` isn't implemented by JS even in comm-central nor
BlueGriffon. Therefore, we can make it a builtinclass.
Additionally, this patch makes all users in C++ use `nsCommandManager` which is
the only implementation of `nsICommandManager`. This avoids QI from
`nsICommandManager` to `nsPICommandUpdater`.
Differential Revision: https://phabricator.services.mozilla.com/D25726
--HG--
extra : moz-landing-system : lando
`PresShell.h` is exposed as `mozilla/PresShell.h` and `PresShell` is the only
concrete class of `nsIPresShell`. Therefore, we have no reason to access
`PresShell` via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D23277
--HG--
extra : moz-landing-system : lando
"cmd_setDocumentOptions" is never used now (even including comm-central and
BlueGriffon). So, we can stop supporting this command and we can get rid of
the command handler, SetDocumentOptionsCommand.
Differential Revision: https://phabricator.services.mozilla.com/D20611
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13073
--HG--
extra : moz-landing-system : lando
Even though HTMLEditor::GetIsCSSEnabled() is an implementation of an XPCOM
method, it uses nsresult as its return type. We should change it to
NS_IMETHODIMP.
Additionally, SetDocumentStateCommand::GetCommandStateParams() calls this,
but HTMLEditor can expose non-virtual method, HTMLEditor::IsCSSEnabled().
Therefore, this patch makes it public and makes SetDocumentStateCommand use
HTMLEditor::IsCSSEnabled().
Differential Revision: https://phabricator.services.mozilla.com/D4304
--HG--
extra : moz-landing-system : lando
We have another built-in UI of editor which is not implemented by any other
browsers. That is a draggable handler to move absolute positioned elements.
So, we should disable it in default for compatibility with the other browsers.
However, different from resizers and inline table editor, we don't have
command to enable/disable this feature but for backward compatibility, we
should have it. Therefore, this patch adds new command
"enableAbsolutePositionEditor".
Note that whether resizing UI is available only with enableObjectResizing
state is different from enableInlineTableEditing command. Resizers for
absolute positioned elements are NOT available both enableObjectResizing
and enableAbsolutePositionEditor are enabled.
Additionally, this adds automated tests to check basic functions of absolute
positioned editor.
MozReview-Commit-ID: 9ZSGB8tLpFw
--HG--
rename : editor/libeditor/tests/test_resizers_appearance.html => editor/libeditor/tests/test_abs_positioner_appearance.html
rename : editor/libeditor/tests/test_resizers_resizing_elements.html => editor/libeditor/tests/test_abs_positioner_positioning_elements.html
extra : rebase_source : d516f3f3ef36d4ad13938f214cb6e3868d7ff407
Gecko supports resizers of <img> elements and <table>, <td>, <th> elements and
has UI to remove existing table row or column in default. However, the other
browsers don't have such UI and web apps need to disable this feature with
calling both:
document.execCommand("enableObjectResizing", false, false);
document.execCommand("enableInlineTableEditing", false, false);
for avoiding conflicting with their own features to edit such elements.
Therefore, it doesn't make sense to keep enabling them in default only on
Gecko. If web apps want to keep using these features, they should call:
document.execCommand("enableObjectResizing", false, true);
document.execCommand("enableInlineTableEditing", false, true);
at initializing the editor.
And also this patch fixes bugs of
document.queryCommandState("enableObjectResizing") and
document.queryCommandState("enableInlineTableEditing"). They always return
false even after calling document.execCommand(..., false, true) since
nsSetDocumentStateCommand::GetCommandStateParams() sets bool value as
STATE_ATTRIBUTE. However, nsHTMLDocument::QueryCommandValue() which is the
caller referring STATE_ATTRIBUTE doesn't treat it as bool value. And also
those commands are related to state of document. Therefore, they should be
return as bool value of STATE_ALL instead. Then,
nsHTMLDocument::QueryCommandState() returns the state as expected. Note that
those commands are supported only by Gecko. So, we don't need to worry about
the compatibility.
Finally, this patch rewrites 2 existing tests to check basic behavior of
resizers and appearance of resizers.
Note that this patch does not add new tests to test inline table editor
since it's difficult to test the behavior with current API. Perhaps, we
should add an API to nsIHTMLEditor to retrieve each anonymous elements in
another bug since it requires to add wrapping API of SpecialPowers.
MozReview-Commit-ID: 1FhYo5vcV60
--HG--
rename : editor/libeditor/tests/test_objectResizing.html => editor/libeditor/tests/test_resizers_appearance.html
rename : editor/libeditor/tests/test_bug640321.html => editor/libeditor/tests/test_resizers_resizing_elements.html
extra : rebase_source : a707de5a64ef1f8ce974cdf1be093d1b4f61c7bc
This is remaining part of bug 1450882. I forgot to update
HTMLEditorDocumentCommands.cpp when I work on the bug.
This patch makes HTMLEditorDocumentCommands.cpp use non-virtual methods of
nsCommandParams instead of virtual methods of nsICommandParams.
MozReview-Commit-ID: 12AjXbeYNOa
--HG--
extra : rebase_source : 8d73866b21f6dd1c436244a771fb39bbe2debd40
nsICommandParams::GetCStringValue() and nsICommandParams::SetCStringValue()
treat char. However, this makes their callers complicated. So, they should
be rewritten as treating nsACString.
MozReview-Commit-ID: DWO9veSyzyG
--HG--
extra : rebase_source : fbea13f6d7116ea1887434c0842b7768a7dc59ec
HTMLEditorController and HTMLEditorCommands is for execCommand, so we should
move from composer to libeditor since HTML editor code is in libeditor.
MozReview-Commit-ID: DEBoTqUsQnw
--HG--
rename : editor/composer/HTMLEditorCommands.cpp => editor/libeditor/HTMLEditorCommands.cpp
rename : editor/composer/HTMLEditorCommands.h => editor/libeditor/HTMLEditorCommands.h
rename : editor/composer/HTMLEditorController.cpp => editor/libeditor/HTMLEditorController.cpp
rename : editor/composer/HTMLEditorController.h => editor/libeditor/HTMLEditorController.h
rename : editor/composer/HTMLEditorDocumentCommands.cpp => editor/libeditor/HTMLEditorDocumentCommands.cpp
extra : rebase_source : 0b9627ac89803212da3377db3dfefedc3b57ce73
Masayuki Nakano
Butkovits Atila
Narcis Beleuzu
Simon Giesecke
Botond Ballo
Gabriele Svelto
Sylvestre Ledru
arthur.iakab
Emilio Cobos Álvarez
Ehsan Akhgari
Cosmin Sabou
Andreea Pavel
Makoto Kato