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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--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
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--HG--
extra : moz-landing-system : lando
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--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
As far as I've tested, Chrome does not throw exception even when editor is
destroyed or editor content is modified unexpectedly. So, we should return
`NS_OK` from most public methods of editor when internal methods return
`NS_ERROR_EDITOR_DESTROYED` or `NS_ERROR_EDITOR_UNEXPECTED_DOM_TREE`.
Differential Revision: https://phabricator.services.mozilla.com/D20811
--HG--
extra : moz-landing-system : lando
Those probes are now expired and we got enough data:
- Almost no user uses the grip to move absolute positioned element
- There were over one thousand users using the inline table editor and the object resizers.
- Such users keep using even after we disabled the UIs by default.
Perhaps, such small number of users keep using the UIs, i.e., I guess the
number won't become smaller in short term. Therefore, this patch removes the
telemetry probes and members of HTMLEditor which are necessary to call
Telemetry API.
Differential Revision: https://phabricator.services.mozilla.com/D20609
--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.
ResizerMouseMotionListener listens to "mousemove" events for resizers
or grabber to move absolutely position element and it calls only
HTMLEditor::MouseMove(). Fortunately, neither EditorEventListener not
HTMLEditorEventListener listens to "mousemove" events. Therefore, we
can use HTMLEditorEventListener instead.
Differential Revision: https://phabricator.services.mozilla.com/D10869
--HG--
extra : moz-landing-system : lando
DocumentResizeEventListener listens to only "resize" events of the window
and when it fired, it just calls HTMLEditor::RefreshResizers(). Fortunately,
neither EditorEventListener nor HTMLEditorEventListener listens to "resize"
events. Therefore, we can move this implementation into
HTMLEditorEventListener.
Differential Revision: https://phabricator.services.mozilla.com/D10866
--HG--
extra : moz-landing-system : lando
DocumentResizeEventListener::HandleEvent() calls protected method,
HTMLEditor::RefreshResizersInternal(). However, this method is an event
handler, i.e., called when the editor is not handling an edit action.
Therefore, for ensuring AutoEditActionDataSetter instance, it should call
public method, nsIHTMLEditor::RefereshResizers() instead.
Differential Revision: https://phabricator.services.mozilla.com/D10706
--HG--
extra : moz-landing-system : lando
AutoTransactionBatch, AutoPlaceholderBatch, AutoSelectionRestorer,
AutoTopLevelEditSubActionNotifier, AutoTransactionsConserveSelection and
AutoUpdateViewBatch access protected members of EditorBase. The access
scope management assume that they are used only by EditorBase or its
subclasses or TextEditRules or its inherited class (i.e., HTMLEditRules).
For guaranteeing this at build-time, we should change them to nested classes
of EditorBase. Then, EditorBase and its subclasses and friends can use them.
Differential Revision: https://phabricator.services.mozilla.com/D9479
--HG--
extra : moz-landing-system : lando
nsIHTMLObjectResizers.resizedObject is used only for avoiding warning of
nsIHTMLObjectResizers.refreshResizers() if resizers are not visible.
Therefore, if we remove the unnecessary warnings, we can get rid of the
attribute.
Differential Revision: https://phabricator.services.mozilla.com/D5427
--HG--
extra : moz-landing-system : lando
HTMLEditor::RefreshResizers() is an XPCOM method but it's used internally. So,
HTMLEditor should implement it with non-virtual method and use new one for
internal use.
This patch also makes related methods nested-creation of resizers aware. This
issue must not be dangerous, but looks like buggy.
Differential Revision: https://phabricator.services.mozilla.com/D5426
--HG--
extra : moz-landing-system : lando
HTMLEditor::HideResizers() is an XPCOM method, so, we should create non-virtual
method for internal use.
Differential Revision: https://phabricator.services.mozilla.com/D4923
--HG--
extra : moz-landing-system : lando
First, nobody uses nsIHTMLObjectResizer.showResizers(). So, we can remove it.
Then, we have two private methods, one is non-virtual
HTMLEditor::ShowResizers(), and the other is HTMLEditor::ShowResizersInner().
HTMLEditor::ShowResizers() calls HTMLEditor::ShowResizersInner() and if
it fails, calls HideResizers(). However, in some cases, e.g., when it already
has visible resizers, hiding resizers does not make sense.
So, this patch removes non-virtual HTMLEditor::ShowResizers() method too,
then, renames HTMLEditor::ShowResizersInner() to HTMLEditor::ShowResizers(),
finally, it hides resizers only when it fails to setup resizers for keeping
resizers hidden.
Differential Revision: https://phabricator.services.mozilla.com/D4921
--HG--
extra : moz-landing-system : lando
Oddly, on 63 Beta simulation, nsIDocument::GetWindow() may return nullptr
when HTMLEditor is being destroyed by unload of the page. I'm not sure if
this is an expected change. However, HTMLEditor::HideResizers() should
not stop cleaning up even if it meets unexpected situation.
Additionally, this patch moves all HTMLEditor members related to resizers
to local variables since while HideResizers() is cleaning up old resizers,
the members may be overwritten by ShowResizers() if mutation event listener
or something does something.
Differential Revision: https://phabricator.services.mozilla.com/D4057
--HG--
extra : moz-landing-system : lando
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 assertion was added by review comment of bug 1487945. Since mutation event
handler of this test case hides resizer, this case hits this assertion.
Although 4th parameter of SetAttr can control mutation event, if this event
isn't fired, another test case (layout/base/tests/test_bug558663.html) becomes
failure.
So we should move the assertion before setting resizer attribute.
Differential Revision: https://phabricator.services.mozilla.com/D1854
--HG--
extra : moz-landing-system : lando
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
HTMLEditor has 2 type of public methods. One is rue-public methods. I.e.,
they should be able to be called by anybody. E.g., command handlers, event
listeners, or JS via nsIEditor interface. The other is semi-public methods.
They are not called by the above examples but called by other classes which
are helper classes to handle edit actions. E.g., TextEditRules, HTMLEditRules,
HTMLEditUtils, CSSEditUtils and Transaction classes.
When we will implement InputEvent.inputType, we need to create new stack
class and create its instance at every true-public methods to manage current
inputType (like TextEditRules::AutoSafeEditorData). Therefore, it should not
happen that new code starts to call semi-public methods without the new
stack class instance.
For preventing this issue, we should make HTMLEditor have only the true-public
methods as public. The other public methods should be protected and their
users should be friend classes. Then, we can protect such method from external
classes.
Note that this patch just moves the methods without any changes in HTMLEditor.h
(except removes BlockTransformationType since it's unused and replaces
ResizingRequestID with new enum class ResizeAt since normal enum isn't hit by
searchfox.org).
MozReview-Commit-ID: 7PC8E8vD7w2
--HG--
extra : rebase_source : 13f51565f2b89ab816ba529af18ee88193a9c932
Gecko has some built-in UIs:
* to edit size of objects like <img>, <table> and absolute positioned elements.
* to edit position of absolute positioned elements.
* to add/remove table columns and rows.
Currently, those UIs are available in both designMode editor and contenteditable
editor only on Gecko. I.e., the other browsers' users cannot modify as such
without web apps implement such function. So, for compatibility with the
other browsers, we should hide those UIs by default. On the other hand, if
this is too risky for backward compatibility, we should not do that.
So, before doing that, we should collect actual usage data of object resizers,
inline table editing UI, positioning UI of absolute positioned elements with
telemetry probes.
This patch adds 3 sets of probes for each UI. One is percentage of showing
each UI in all instantiated HTMLEditor. The other is number of user interaction
of each UI in HTMLEditors which has shown the UI.
This patch makes all new probes as "opt-out" because they are really important
data since used for deciding whether those UIs are necessary or unnecessary.
MozReview-Commit-ID: B9Y6GTiCPw6
--HG--
extra : rebase_source : 00e49f31712e24cb269ad3aa65c7d13b7cccb3a5
