Currently, if you need to unmask all password characters, you need to call
`nsIEditor.unmask(0)`. However, this is ugly and this must be the most use
case. So, I think that we should make it optional.
Differential Revision: https://phabricator.services.mozilla.com/D39327
--HG--
extra : moz-landing-system : lando
It does not make sense to copy masked password with mask characters.
Therefore, we should allow users to copy/cut in password fields only when
selected range is in unmasked range.
Note that for web-compat, copy/cut are always enabled in HTML/XHTML document
in content. Therefore this patch changes the behavior only in chrome's
password fields.
Additionally, only the test uses `nsIEditor.canDelete()`. Therefore, this
removes it and make the test use `nsIDocShell.isCommandEnabled()` instead.
Unfortunately, `nsIEditor.canCopy()` and `nsIEditor.canCut()` are used by
BlueGriffon, therefore, we cannot get rid of them for now.
Differential Revision: https://phabricator.services.mozilla.com/D38999
--HG--
rename : editor/libeditor/tests/test_bug1067255.html => editor/libeditor/tests/test_cut_copy_delete_command_enabled.html
extra : moz-landing-system : lando
Unmasking is an optional style of showing password. Therefore, if callers of
`nsIEditor::Unmask()` specify middle of surrogate pair(s), it may mean that
they want to expand the unmask range from shorter range which does not include
the high and/or low surrogate. Therefore, one of the surrogates is in unmasked
range, we unmask the surrogate pair. However, we handle this in a lot of
places, i..e., we have duplicated code. This can get rid of these duplicates
with making `nsIEditor::Unmask()` expand the range automatically.
Differential Revision: https://phabricator.services.mozilla.com/D38432
--HG--
extra : moz-landing-system : lando
This patch creates editor API to get/set unmask-range of password field.
Its design is similar to `setSelectionRange()` and `selectionStart`/
`selectionEnd` attributes. The unmasked range is automatically
masked if `aTimeout` of `unmask()` is set to non-zero.
Otherwise, unmasked range won't be masked automatically even after user
or web apps modifies the editor, and inserting new character expands
unmasking range.
The following patch makes `TextEditRules` use these API to implement
delayed masking of password.
Note that editor has never supported dynamic `eEditorPasswordMask` change.
E.g., if you have typed some characters into an editor and toggle the flag,
the characters are not unmasked nor masked. Then, if you type new characters,
only they are correctly masked or unmasked. This patch puts `MOZ_ASSERT()`
to reject this feature completely on debug build for making the unmasking
implementation simpler.
Differential Revision: https://phabricator.services.mozilla.com/D38004
--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
`CanCut()`, `CanCopy()` and `CanPaste()` return error only when the editor has
already been destroyed or not been initialized yet, or when failed to access
clipboard when the document is not HTML/XHTML.
`CanDelete()` returns error only when the editor has already been destroyed or
not been initialized yet.
So, these error result won't be exposed to the web in most cases and such
exception shouldn't stop any content script because Chrome basically does not
throw exception in such situation as far as I know.
Therefore, there should be overloads of them to return `bool` result directly
for making their callers simpler.
Differential Revision: https://phabricator.services.mozilla.com/D28608
--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
`EditorBase::SelectEntierDocument()` uses `Selection::Extend()` but it's too
slow. It should use `Selection::SetStartAndEndInLimiter()` instead.
Additionally, `TextEditor::SelectEntierDocument()` shrink the result of
`EditorBase::SelectEntierDocument()` with `Selection::Extend()` if there is
a `moz-<br>` element. So, `TextEditor::SelectEntinerDocument()` should set
its expected selection with a call for saving the runtime cost.
Then, we don't need to make `EditorBase::SelectEntierDocument()` as non-pure
virtual method. So, this patch makes each its callers call
`Selection->SelectAllChildren()` directly.
Differential Revision: https://phabricator.services.mozilla.com/D23461
--HG--
extra : moz-landing-system : lando
`EditorBase::SelectEntierDocument()` uses `Selection::Extend()` but it's too
slow. It should use `Selection::SetStartAndEndInLimiter()` instead.
Additionally, `TextEditor::SelectEntierDocument()` shrink the result of
`EditorBase::SelectEntierDocument()` with `Selection::Extend()` if there is
a `moz-<br>` element. So, `TextEditor::SelectEntinerDocument()` should set
its expected selection with a call for saving the runtime cost.
Then, we don't need to make `EditorBase::SelectEntierDocument()` as non-pure
virtual method. So, this patch makes each its callers call
`Selection->SelectAllChildren()` directly.
Differential Revision: https://phabricator.services.mozilla.com/D23461
--HG--
extra : moz-landing-system : lando
Since bug 1491173 is landed, there is no users of dumpContentTree,
debugDumpContent and debugUnitTests. So Let's remove these methods from
nsIEditor.
Differential Revision: https://phabricator.services.mozilla.com/D10029
--HG--
extra : moz-landing-system : lando
nsIEditor::ShouldTxnSetSelection() is used only by DeleteRangeTransaction
(even if including comm-central and BlueGriffon) and there is a non-virtual
method EditorBase::GetShouldTxnSetSelection(). So, we can remove this.
MozReview-Commit-ID: JWSCw9k6lI0
--HG--
extra : rebase_source : 2509274216a1493134757a7d106464f06ea0ba57
There are two similar methods, but they are created with copy & paste.
So, the common code should be merged into new method, SetTextDirection().
Additionally, EditorBase::SwitchTextDirection() is a scriptable method but
nobody uses this from JS. So, we can make it from nsIEditor and this
patch renames it to ToggleTextDirection() since current name is too
similar to SwitchTextDirectionTo().
MozReview-Commit-ID: BX3M1OKxiD5
--HG--
extra : rebase_source : 74a5ff65adc96ba69792f2e63daf14828c505270
CanPasteTransferable and PreDestroy aren't used from script (inc. comm-central
and bluegriffon), so we should move these to out of nsIEditor.
MozReview-Commit-ID: GRfBobAm2qi
--HG--
extra : rebase_source : 812792ff43da24bfd9cb99c4b3127e6acdc43ba1
No one uses outputToStream even if c-c and BlueGriffon. We should remove this.
MozReview-Commit-ID: LEUtfc89DBe
--HG--
extra : rebase_source : f0c5aa918f577ca8a285afd2414fe3da6545fefc
No one uses postCreate from script even if c-c and BlueGriffon. So we should
devirtualize this
MozReview-Commit-ID: D3FKVEvG7Go
--HG--
extra : rebase_source : 9915a93ea8ae18bee251507a4c94fe66c0f03d0f
No one uses syncRealTimeSpell from script even if c-c and BlueGriffon. So
we should devirtualize this
MozReview-Commit-ID: AoOb165dOFa
--HG--
extra : rebase_source : e1a9dcdfa6cfe6c918a06a2738c38a6cb9441a1d
So, this patch replaces the setter with non-virtual method and removing the
getter since where is already non-virtual getter method.
MozReview-Commit-ID: Is19Yriz8t8
--HG--
extra : rebase_source : bb2f49f380ddb2e2f96e8690effd8d47d24ae0ae
nsIEditor.numberOfUndoItems and nsIEditor.numberOfRedoItems are shortcut
property for nsITransactionManager.numberOfUndoItems and
nsITransactionManager.numberOfRedoItems of the editor. However, anybody
uses nsITransactionManager directly. So, we can get rid of them.
MozReview-Commit-ID: 70J0bsxDNCC
--HG--
extra : rebase_source : fd0847687fe595b257b0256a5f1faa5f2df5f972
Currently, HTMLEditor doesn't initialize caret position when it gets focus by
itself in most cases. Only when it's in designMode, it may move caret to the
first visible (not checking CSS actually).
In most cases, caret position is adjusted when EditorBase::InitializeSelection()
calls Selection::SetAncestorLimiter(). If selected range is outside of
new limiter, it moves caret to start of the new limiter. However, this is
really different behavior from the other browsers. The other browsers try
to move caret to the first editable text node or before the first editable
content such as <img>, <input>, etc.
This difference causes a serious incompatible issue with Draft.js. It doesn't
initialize caret position when it gets focus but it assumes that caret is
always set to before <br> element if there is no other content.
So, let's try to behave as what other browsers do as far as possible.
This patch makes editor behave as:
* if selection is already in the editing host except start of the editing host,
does nothing.
* if there is non-editable element before any editable node, move caret to
start of the editing host.
* if there is editable text node or element node which cannot have a text node,
move its start or before it.
* if there is no editable nodes which can contain text nodes, move caret to
start of the editing host.
Note that before applying this patch, in designMode, BeginningOfDocument() used
document element instead of <body> element. Therefore, it may set odd position
if <head> element has some text nodes with <script> or <style>. However,
this doesn't make sense and for making more consistent behavior between
designMode and contenteditable, this patch makes it use editing host (it's
<body> element if it's in designMode).
MozReview-Commit-ID: 5neYoTMq6Cc
--HG--
extra : rebase_source : c4d06b6864a221d7cd2833a007d73f7d67821e95
Since We can use EditorBase/TextEditor/HTMLEditor directly, we can
movei noscript methods in nsIEditor to each class.
Also, Init is unnecessary to use nsIDOMDocument and nsIContent since method
isn't in IDL. And some methods are unused now.
MozReview-Commit-ID: D3B6oSlcT0L
--HG--
extra : rebase_source : 6cab2e6e7b4ba8cfb56d8320be24ca4afcbe55fb
extra : amend_source : 1d8c59086a9158a49dd270b64ecf8341ed4002ce
nsIHTMLEditor has several scriptable methods (addDefaultProperty(),
removeDefaultProperty(), etc.) that have nsIAtom parameters. We're in the
process of deCOMtaminating nsIAtom (bug 1392883) so these methods need to be
changed.
This patch does the following.
- It changes those methods to take an AString instead of an nsIAtom.
- For each existing method, it adds to HTMLEditor a new C++ method of the same
name that takes an nsIAtom parameter.
- It updates TextEditorTest.cpp to use strings instead of atoms, in order to
keep using the XPIDL methods.
- It updates test_bug1140105.html to pass strings instead of atoms to
getInlineProperty(). This removes the use of nsIAtomService.
--HG--
extra : rebase_source : e005c3b5a08207b3d5d5fb55c47c8bc475b33453
AutoPlaceHolderBatch can take EditorBase class and its inherited class, AutoEditBatch, can be removed if we implement other constructor which doesn't take transaction name.
Additionally, nsIEditor::(Begin|End)PlaceHolderTransaction() are referred only by AutoPlaceHolderBatch. Therefore, they can be non-public methods and removed from nsIEditor interface.
Note that this patch also repalces "PlaceHolder" with "Placeholder" since it's a word.
MozReview-Commit-ID: 5dw3kcX3bOx
--HG--
extra : rebase_source : e926cc1c2ebea70eb08e43778a8b52912b559b7b
nsIEditor is still first contact with editor class for some modules. They should be accessible to the concrete classes without QI. Therefore, nsIEditor should have As*Editor() methods.
Additionally, this adds AsEditorBase(). That is always implemented but it might be necessary for some files for minimizing its include files.
MozReview-Commit-ID: 8WqkDJLiVDs
--HG--
extra : rebase_source : e51282df244efad62bc6fe04ab449e3beab440f9
If we make nsIEditor a builtin class, that means that its instance can be only TextEditor or HTMLEditor. Then, users of nsIEditor can use concrete classes such as EditorBase, TextEditor or HTMLEditor instead. Then, the users can reduce unnecessary QI and a lot of virtual calls if we'll create non-virtual methods.
So, let's make editor related interfaces builtin classes.
MozReview-Commit-ID: 93WfsSDuJiJ
--HG--
extra : rebase_source : 39151eb4ffaaf195fec57234ea84c9f4066c58d1
There are no app which replaces transaction manager of editor. Additionally, replacing transaction manager of an editor with different editor or same editor but after initialized again due to some reasons may cause unexpected problems.
Therefore, this patch makes it readonly.
MozReview-Commit-ID: K7zepOjrzvC
--HG--
extra : rebase_source : ee1944af57c8102628b8cffbc720d2b8e5e9088d
Doing QI from nsIEditor to nsIEditorIMESupport doesn't make sense because editor should always support all methods and attributes of nsIEditorIMESupport (it does NOT mean that all nsIEditor implementation need to support IME).
This patch moves all of them to nsIEditor for avoiding redundant QIs.
MozReview-Commit-ID: DzIKuGHG4iy
--HG--
extra : rebase_source : cc5e9a6ae4572ebe461d9770ffa5c23d33dc8526
Masayuki Nakano
Oana Pop Rus
Noemi Erli
Boris Zbarsky
Makoto Kato
Nicholas Nethercote
Adrian Wielgosik
Ehsan Akhgari
Mats Palmgren
Olli Pettay
Birunthan Mohanathas