`HTMLEditRules::WillLoadHTML()` does exactly same thing as
`EditorBase::EnsureNoPaddingBRElementForEmptyEditor()`. Therefore, we can
get rid of it and make `HTMLEditor::LoadHTML()` not use `HTMLEditRules`.
Differential Revision: https://phabricator.services.mozilla.com/D41160
--HG--
extra : moz-landing-system : lando
`TextEditRules::CreatePaddingBRElementForEmptyEditorIfNeeded()` is used by
both `TextEditor` and `HTMLEditor` so that this moves it into `EditorBase`.
Additionally, making `TextEditor::MaybeChangePaddingBRElementForEmptyEditor()`
call it if there is no content. Then, we can avoid the dependency of them.
Differential Revision: https://phabricator.services.mozilla.com/D41159
--HG--
extra : moz-landing-system : lando
`TextEditRules::RemoveRedundantTrailingBR()` is used only by multiline text
editor (i.e., `<textarea>`). Therefore, it should be moved into `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D41158
--HG--
extra : moz-landing-system : lando
`TextEditRules::WillUndo()` and `TextEditRules::WillRedo()` only check whether
the editor is readonly/disabled or not. So, `TextEditor::UndoAsAction()` and
`TextEditor::RedoAsAction()` should do it first.
`TextEditRules::DidUndo()` and `TextEditRules::DidRedo()` only set or unset
`mPaddingBRElementForEmptyEditor` if it's restored by undo or redo.
Therefore, we can move the code into `TextEditor::UndoAsAction()` and
`TextEditor::RedoAsAction()`.
Note that this patch makes `TextEditor::UndoAsAction()` discard the result of
`TransactionManager::Undo()` because this is inconsistent from what
`TextEditor::RedoAsAction()` does and this was changed by part 5 of bug 1447924.
https://hg.mozilla.org/mozilla-central/rev/869a1445816be7f43f54f7c97f28e4c6273fa75f
Differential Revision: https://phabricator.services.mozilla.com/D41157
--HG--
extra : moz-landing-system : lando
`TextEditRules::WillInsert()` is not used with initial purpose since
`HTMLEditor` always works with `HTMLEditRules` and its `WillDoAction()`
always handles `EditSubAction::eInsertElement`.
Additionally, its name is too generic since it does non-related 3 things.
One is checking whether the editor is readonly or disabled. However, this
may not be necessary since its callers may have already checked it or
just ignored the result. So, this should be check by each caller.
Next one is masking password if auto-masking is enabled. This is `TextEditor`
specific feature so that this patch moves the code into
`TextEditor::MaybeDoAutoPasswordMasking()`.
Final one is removing empty `<br>` element for empty editor if there is.
This is common feature so that this patch moves this code into
`EditorBase::EnsureNoPaddingBRElementForEmptyEditor()`.
Differential Revision: https://phabricator.services.mozilla.com/D41156
--HG--
extra : moz-landing-system : lando
`TextEditRules::mPaddingBRElementForEmptyEditor` are used by both `TextEditor`
and `HTMLEditor`. Therefore, it should be in `EditorBase`.
This patch makes `TextEditRules` and `HTMLEditRules` directly access the
private member of `EditorBase` temporarily. It'll be fixed by the following
patches.
Differential Revision: https://phabricator.services.mozilla.com/D41155
--HG--
extra : moz-landing-system : lando
This allows users of `WSRunScanner`'s functionality to pass a `const
HTMLEditor*`, allowing themselves to become const-correct.
Differential Revision: https://phabricator.services.mozilla.com/D41384
--HG--
extra : moz-landing-system : lando
We check surrogate pair at specific index in `nsTextFragement` in a lot of
places. This requires boundary check of the index so that it can cause
security issue and crash reason with simple mistake, and also it steals
your time to understand the code what it does especially when it's a
part of an `if` condition.
Therefore, this patch adds new API to `nsTextFragment` and makes the all
surrogate pair handlers of `nsTextFragument` use new API.
Differential Revision: https://phabricator.services.mozilla.com/D39689
--HG--
extra : moz-landing-system : lando
Original regression was by bug 1362858, and bug 1418629 wasn't enough to fix.
By bug 1362858, we use `CHAR_CLASS_SEPARATOR` in additional to DOM word separator. But some characters such as single quote, `@` and etc are `CHAR_CLASS_SEPARATOR`, so we may check spell by incomplete word.
We shouldn't separate word by characters that is email part, URL part or conditional punctuation.
And I also update test cases for this situation. `<textarea>` is better for spell checking since it can has multiple anonymous text nodes.
Differential Revision: https://phabricator.services.mozilla.com/D39829
--HG--
extra : moz-landing-system : lando
When using `<textarea>`, spell checker sometimes check spell when editing last text node. Because editor passes invalid previous selection node and offset via `HandleInlineSpellCheck`.
Although previous selected node uses `mCachedSelectionNode` that is stored by `BeforeEdit`, when this occurs, it isn't text node.
When editing last text node in `<textarea>`, anchror node might be root node, not current text node. So we should use text node instead when this is inserting text operation.
Differential Revision: https://phabricator.services.mozilla.com/D40368
--HG--
extra : moz-landing-system : lando
Stopping using attribute for "moz-br", `IMEContentObserver` cannot know when
new `<br>` element is changed to padding element for empty last line.
Therefore, editor needs to insert padding `<br>` element after setting the
flag properly. Then, `IMEContentObserver` does not need to recompute the
length of `<br>` element (if it's for padding, it computes the length as 0).
Unfortunately, `TextEditor::InsertBrElementWithTransaction()` is used in too
many places and it already has optional argument. Therefore, it's difficult
to change it. However, we should share the preparation before creating `<br>`
element in it with new method. Therefore, this patch creates
`EditorBase::PrepareToInsertBRElement()` to share the preparation point (almost
just moved from the method). Then, new method is created as
`EditorBase::InsertPaddingBRElementForEmptyLastLineWithTransaction()` because
it's used both in `TextEditor` and `HTMLEditor`. Finally, `TextEditor` won't
insert `<br>` element with `InsertBrElementWithTransaction()`. Therefore, it's
moved to `HTMLEditor` with renaming to `InsertBRElementWithTransaction()`.
Differential Revision: https://phabricator.services.mozilla.com/D39860
--HG--
extra : moz-landing-system : lando
`TextEditRules::CreateBR()` is used only by
`HTMLEditRules::InsertBRIfNeededInternal()` and it just calls
`TextEditor::InsertBrElementWithTransaction()`. Therefore, we can get rid of
it. Then, `CreateBRInternal()` can be renamed to
`CreatePaddingBRElementForEmptyLastLine()` since it's shared only by
`CreateBR()` and `CreatePaddingBRElementForEmptyLastLine()`.
Differential Revision: https://phabricator.services.mozilla.com/D39859
--HG--
extra : moz-landing-system : lando
Editor creates a `<br>` element to end of a block if last line
of the block is empty because caret should be placed as there is an empty
line. Such special `<br>` element has `type` attribute whose value is "_moz".
However, adding/removing the attribute is expensive and such hacky attribute
shouldn't be referred nor changed by web apps.
Therefore, this patch makes `HTMLBRElement` take another specific flag whether
it's a special node for empty last line. For making the meaning clearer,
this patch calls the such `<br>` elements as "padding `<br>` element for
empty last line" insead of "moz-br". So, this patch also includes a lot of
renaming methods and variables, and modifying related comments.
Note that with this change, `IMEContentObserver` counts the padding `<br>`
element in `<textarea>` because it's inserted before setting the new flag
and setting the flag does not cause DOM tree mutation. This issue will be
fixed by the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D39858
--HG--
extra : moz-landing-system : lando
Editor creates a `<br>` element when it's root element is empty.
Then, it's stored by `TextEditRules::mBogusNode` and used for checking
whether the editor is empty quickly. However, this `<br>` element has
`mozeditorbogusnode` attribute whose value is `true`. However, adding or
removing the attribute is not cheap and web apps can refer such illegal
attribute.
Therefore, this patch makes `HTMLBRElement` take a specific flag whether
it's a bogus node or not. However, this means that this hacky thing will be
exposed outside editor module. For making what is the bogus node clearer,
this patch calls the such `<br>` elements as "padding `<br>` element for
empty editor". So, this patch also includes a lot of renaming methods and
variables, and modifying related comments.
Differential Revision: https://phabricator.services.mozilla.com/D39857
--HG--
extra : moz-landing-system : lando
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
`aStart` of `TextEditor::SetUnmaskRangeInternal()` may be `UINT32_MAX` if
it's called for stopping unmasking. However, it returns `NS_ERROR_INVALID_ARG`
if there is no text node and `aStart` is not 0, but this is unexpected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D39326
--HG--
extra : moz-landing-system : lando
First, we need to make `nsCopySupport::FireClipboardEvent()` keep handling
`eCopy` and `eCut` event even in password field, only if `TextEditor` allows
them.
Then, we need to make `nsPlainTextSerializer::AppendText()` not expose
masked password for making users safer. Although `TextEditor` does not allow
`eCopy` nor `eCut` when selection is not in unmasked range. Fortunately,
retrieving masked and unmasked password from `nsTextFragment` has already
been implemented in `ContentEventHandler.cpp`. This patch moves it into
`EditorUtils` and makes `ContentEventHandler.cpp` and `nsPlaintextSerializer`
share it.
Differential Revision: https://phabricator.services.mozilla.com/D39000
--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
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
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
Double click, long tap, moving selection with keyboard and deleting text
scan word boundary. With these changes, the text node has raw password
value even if it's masked visually. For making safer,
`nsTextFrame::PeekOffsetWord()` should search word boundary in masked text.
Then, we can hide word boundary at masked range, but keep allowing to look
for word boundary only in unmasked range.
Differential Revision: https://phabricator.services.mozilla.com/D38013
--HG--
extra : moz-landing-system : lando
Anonymous text node in password field has `NS_MAYBE_MASKED` flag and
`TextEditor` managing the node has range of unmasking. This patch makes
`BuildTextRunsScanner::BuildTextRunForFrames()` treat text frame in
password field as `text-transform` applied. For recording the unmask range,
this patch creates `nsTransformedCharStyle::mMaskPassword` and treats unmask
range start/end edges as different style boundary. Therefore,
`nsCaseTransformTextRunFactory::TransformString()` can replace each character
with a password mask character with the information.
Note that we need to kill bidi algorithm in password fields with forms.css
because caret position will tell everybody whether the typing character is
an RTL or an LTR character.
Differential Revision: https://phabricator.services.mozilla.com/D38009
--HG--
extra : moz-landing-system : lando
With the previous patches, editor has stopped masking characters in password
field. Instead, layout code needs to handle it. However, layout code
especially around `nsTextFrame` is performance critical area. Therefore,
layout code requires a quick way to check whether a text node in password
field or not.
This patch creates new flag for `CharacterData` node and marks all text nodes
whose characters should be masked with the flag when `EditorBase` or
`nsTextControlFrame` creates them.
Differential Revision: https://phabricator.services.mozilla.com/D38006
--HG--
extra : moz-landing-system : lando
Now, `TextEditRules` should use the new editor API to mask/unmask characters
if it's for a password editor. With this change, it does not need to manage
masked characters and unmasked characters separately since the anonymous
text node always have unmasked characters and `nsTextFrame` will mask the
characters at painting time.
Differential Revision: https://phabricator.services.mozilla.com/D38005
--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
In the next patch, we need to update unmasked range when anonymous text node
in `<input type="password">` is modified. This patch makes editor manage it
easier to update the range.
Note that the next patch also handles text node creation and destruction.
Differential Revision: https://phabricator.services.mozilla.com/D38003
--HG--
extra : moz-landing-system : lando
This will have two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
Previously, `runRemoveContentTest()` was the last test which synthesizes
composition in the `<textarea>`. However, new test order move it to middle
of the other tests. Then, it hits an `MOZ_ASSERT()` in
`TextComposition::EditorWillHandleCompositionChangeEvent()` that detects a
bug. When editable element is removed from the DOM tree during a composition,
editor cannot listen to `eCompositionEnd` event. Therefore, when the editor
gets back, it still has destroyed `TextComposition` and keeps handling new
composition with the old one. Therefore this patch makes
`EditorBase::InstallEventListeners()` forget the destroyed composition.
Differential Revision: https://phabricator.services.mozilla.com/D37061
--HG--
extra : moz-landing-system : lando
To avoid populating the clipboard cache,
`nsContentUtils::IPCTransferableToTransferable` should set the
IsPrivateData flag on the output transferable BEFORE assigning data to
it, not therafter.
This patch includes a new regression test for this specific scenario.
The patch also includes fixes for incorrect IsPrivateData flags in some
other locations with `transferable->Init(nullptr)`, but without unit
tests.
Differential Revision: https://phabricator.services.mozilla.com/D36440
--HG--
extra : moz-landing-system : lando
This will have two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
Since JSWindowActors don't have direct access to synchronous messaging,
ChromeScript callers are going to need to migrate to asynchronous messaging
and queries instead.
Since there's no comparable API to sendQuery for frame message managers, this
patch adds a stub that uses synchronous messaging, but makes the API appear
asynchronous, and migrates callers to use it instead of direct synchronous
messaging. This will be replaced with a true synchronous API in the actor
migration.
Fortunately, most of the time, this actually leads to simpler code. The
`sendQuery` API doesn't have the odd return value semantics of
`sendSyncMessage`, and can usually just be used as a drop-in replacement. Many
of the `sendSyncMessage` callers don't actually use the result, and can just
be changed to `sendAsyncMessage`. And many of the existing async messaging
users can be changed to just use `sendQuery` rather than sending messages and
adding response listeners.
However, the APZ code is an exception. It relies on intricate properties of
the event loop, and doesn't have an easy way to slot in promise handlers, so I
migrated it to using sync messaging via process message managers instead.
Differential Revision: https://phabricator.services.mozilla.com/D35055
--HG--
extra : rebase_source : d5707e87f293a831a5cf2e0b0a7e977090267f78
extra : source : 75ebd6fce136ab3bd0e591c2b8b2d06d3b5bf923
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 941298157e7c82f420cf50ce057154ce9b85301c
extra : source : 189dc8a359815e059a4a217f788d183260bb2bfe
`EditorSpellCheck` clones `nsRange` instance only for temporary use during
initialization even though the DOM tree won't be changed during it. In this
case, using `StaticRange` is better since it does not need to observe the
DOM tree mutation. I.e., we can save the cost of registering and
unregistering the mutation observer.
Differential Revision: https://phabricator.services.mozilla.com/D35146
--HG--
extra : moz-landing-system : lando
This patch makes `HTMLEditRules::PinSelectionToNewBlock()` use `StaticRange`
instead of `nsRange` for comparing a point and a range (i.e., the DOM tree
won't be changed during it's alive). Unfortunately, we still have allocation
cost, but we can save the cost of registering and unregistering mutation
observer and computing common ancestor of the range.
Differential Revision: https://phabricator.services.mozilla.com/D35145
--HG--
extra : moz-landing-system : lando
This patch makes `HTMLEditRules::ExpandSelectionForDeletion()` use `StaticRange`
instead of `nsRange` for comparing a point and a range (i.e., the DOM tree
won't be changed during it's alive). Unfortunately, we still have allocation
cost, but we can save the cost of registering and unregistering mutation
observer and computing common ancestor of the range.
Differential Revision: https://phabricator.services.mozilla.com/D35144
--HG--
extra : moz-landing-system : lando
Some `nsRange` static methods are useful in `StaticRange` and some of them
are used in a lot of places but not related to `nsRange` directly. This
patch moves them into new static method only class, `mozilla::RangeUtils`.
Differential Revision: https://phabricator.services.mozilla.com/D35142
--HG--
extra : moz-landing-system : lando
For avoiding confusion between API of `nsRange` and `StaticRange`, I'd like to
rename `nsRange::CreateRange()` to `nsRange::Create()` because
`StaticRange::CreateStaticRange()` is too long name and
`StaticRange::CreateRange()` sounds odd. This patch renames it and changes
related methods to template methods to avoid runtime cost of temporary
`RawRangeBoundary` instance creation.
Differential Revision: https://phabricator.services.mozilla.com/D35141
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
Temporary workaround to use the document element as the root content node
in XHTML pages that have a XUL root element.
Differential Revision: https://phabricator.services.mozilla.com/D34657
--HG--
extra : moz-landing-system : lando
Currently, `HTMLEditor::GetSelectedElement()` is not used in mozilla-central
and mainly used for handling double clicks in the editor with its complicated
path. In most cases, users don't want double clicks to cause showing
property dialog in mail composer. Therefore, we must be able to stricter in
the complicated path.
This patch adds new check whether the selected range ends immediately before
a `<br>` element. If it's end at a `<br>` element, we shouldn't treat found
element as selected.
Note that when `<a href="...">` element is double-clicked, the element itself
is selected like `<img>` element. So, we don't need to worry about the case
which is that users probably want to update a link with double-clicking since
such case is handled by the first optimized path in the method.
Differential Revision: https://phabricator.services.mozilla.com/D34335
--HG--
extra : moz-landing-system : lando
Chromium removes new empty blocks only when the content is removed by dragging.
Before bug 1504910, we just removed the dragged range, i.e., kept the new
empty blocks. However, now, we put `<br>` element from
`HTMLEditRules::AfterEditInner()` because a D&D action was split to the deletion
part and inserting part (It wasn't called after inserting the dropped content).
Therefore, this patch adds new path for D&D into
`HTMLEditRules::WillDeleteSelection()`. If parent blocks become empty,
the path removes such blocks and collapse `Selection` to where the most
ancestor empty block was. With this patch, we get same behavior as Chrome
in most cases. You can check it in https://jsfiddle.net/d_toybox/9px07yLr/
Differential Revision: https://phabricator.services.mozilla.com/D34147
--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
Currently, `Document` converts HTML command (e.g., used by `execCommand()`) to
internal XUL command with array in the global space. However, it requires scan
of the array for every command access.
This patch makes `Document` use hashtable to make the conversion faster.
New mapping info comes from:
- `mXULCommandName` is same as `internalCommandString`
- `mCommand` is mapped in CommandList.h from `mXULCommandName`
- `mGetEditorCommandFunc` is mapped from `mXULCommandName` in:
- https://searchfox.org/mozilla-central/rev/d143f8ce30d1bcfee7a1227c27bf876a85f8cede/editor/libeditor/EditorController.cpp#31-32,34-38,40-41,43,45-51,54-57,67-112
- https://searchfox.org/mozilla-central/rev/75294521381b331f821aad3d6b60636844080ee2/editor/libeditor/HTMLEditorController.cpp#26-28,31-39,48,51-52,55-58,60-63,65-73,76-80,83-88,90-91,93-94,97-100,102-104
- `mExecCommandParam` is converted from `useNewParam` and `convertToBoolean`:
- If corresponding editor command class's `DoCommandParam()` just calls
`DoCommand()`, `ExecCommandParam::Ignore`.
- If `useNewParam` is `true` and `convertToBoolean` is `false`, given value
should be ignored and may set constant instead. In this case,
`ExecCommandParam::Ignore`.
- If `useNewParam` is `false` and `convertToBoolean` is `false`, given value
should be treated as string. In this case, `ExecCommandParam::String`.
- If `useNewParam` is `false` and `convertToBoolean` is `true`, given value
should be treated as bool. In this case, if given command is not a legacy
one, `ExecCommandParam::Boolean`. Otherwise, i.e., if given command
is a legacy one, `ExecCommandParam::InvertedBoolean`.
- Otherwise, `ExecCommandParam::String`.
Differential Revision: https://phabricator.services.mozilla.com/D29628
--HG--
extra : moz-landing-system : lando
Some methods in `nsIEditingSession` isn't used from script. So we should move
these to `nsEditingSession` or add `[noscript]`.
Differential Revision: https://phabricator.services.mozilla.com/D33606
--HG--
extra : moz-landing-system : lando
Having NAC bound to the tree when not connected is not quite fine, make sure to
clean up properly.
Differential Revision: https://phabricator.services.mozilla.com/D33704
--HG--
extra : moz-landing-system : lando
`HTMLEditor` initializes selection ancestor limit when it receives `focus`
event. If `Document.execCommand()` is called immediately after an
ancestor of active editing host becomes new editing host,
`HTMLEditor::GetActiveEditingHost()` returns the new one, but selection
ancestor limit is still the previous one. This mismatch causes a lot of
bugs. Therefore, this patch makes `nsGenericHTMLElement` notifies `HTMLEditor`
of an element becoming `contenteditable`, and makes `HTMLEditor` update
selection ancestor limit only when the new editing host is ancestor of
old selection ancestor limit.
Differential Revision: https://phabricator.services.mozilla.com/D32823
--HG--
extra : moz-landing-system : lando
`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
--HG--
extra : moz-landing-system : lando
BindContext was going to have way more information at first, but then I realized
that most of the things I wanted to know were basically a flag away using the
parent node.
Still I think it's worth it, now experimenting with BindToTree will only mean
adding a field to a struct that's included from a couple cpp files, instead of a
massive pain.
I also think this is clearer, and doing this highlights quite a few
inconsistencies in our code which I've left untouched, but commented with
FIXMEs.
Steps are:
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsresult BindToTree(Document\* aDocument, nsIContent\* aParent,#nsresult BindToTree(BindContext\&, nsINode\& aParent)#g' $file; done
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's# nsIContent\* aBindingParent) override#override#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(Document\* aDocument, nsIContent\* aParent,#::BindToTree(BindContext\& aContext, nsINode\& aParent)#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsIContent\* aBindingParent)##g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(aDocument, aParent, aBindingParent)#::BindToTree(aContext, aParent)#g' $file; done
$ ./mach clang-format
Then manual fixups.
Depends on D32948
Differential Revision: https://phabricator.services.mozilla.com/D32949
I think this is a good change regardless of other discussion in bug 1552587. If
we decide to move `mColor` to the top-level of the struct that can be done
separately.
Differential Revision: https://phabricator.services.mozilla.com/D32726
--HG--
extra : moz-landing-system : lando
`aPointAfterInsertedString` of `WSRunObject::InsertText()` is optional (i.e.,
may be nullptr). However, the fix for bug 1534394 makes it always set to
original insertion point when `InsertTextWithTransaction()` is failed.
This patch just make it check if `aPointAfterInsertedString` is nullptr before
setting its value.
Differential Revision: https://phabricator.services.mozilla.com/D33144
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::ApplyBlockStyle()` stores `curBlock` and `newBlock` during its
loop to keep handling from deeper child to ancestor, and may do two things for
a `curNode`. If `curBlock` and/or `newBlock` is moved from expected container
when it sets one of or both of them, this patch check whether mutation event
listeners change the DOM tree. Additionally, this patch also checks whether
`curNode' is moved by mutation event listener at first step of two jobs for it.
Differential Revision: https://phabricator.services.mozilla.com/D32689
--HG--
extra : moz-landing-system : lando
`WSRunObject` scans previous and next node of given point/range **without**
checking editing host boundary. Therefore, its methods may return non-editable
nodes or editable nodes in another editing host. In such cases, `HTMLEditRules`
is confused.
This patch makes it store editing host at initialization and it check the
boundary. However, the former cost may appear in score of some benchmark
tests, but we shouldn't allow attackers to use this entrance.
Differential Revision: https://phabricator.services.mozilla.com/D32467
--HG--
extra : moz-landing-system : lando
Currently, `nsISelectionDisplay::DISPLAY_ALL` is used only by `HTMLEditor`.
And only when it's set, `nsImageFrame::ShouldDisplaySelection()` returns `false`
if only its `mContent` is selected. However, this is based on an assumption,
that is, when only one `<img>` is selected in an HTML editor, it's target of
resizers. However, this is completely wrong. Web apps can disable resizers
with `document.execCommand("enableObjectResizing", false, false)` and now,
it's disabled by default.
Therefore, this patch makes the method check whether its `mContent` is
target of resizers at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D32449
--HG--
extra : moz-landing-system : lando
test_CF_HTML_clipboard.html does nothing if platform isn't mac. But according
to intermittent failure log, this is often failure on Android.
I guess that this is infra issue, but we should use skip-if to avoid this
failure instead.
Differential Revision: https://phabricator.services.mozilla.com/D32413
--HG--
extra : moz-landing-system : lando
Oddly, `WSRunObject::InsertText()` returns `NS_OK` even when
`HTMLEditor::InsertTextWithTransaction()` returns error. However,
it fails if insertion point is not editable like `<noscript>` element.
In such case, `aPointAfterInsertedString` isn't modified and its caller,
`HTMLEditRules::WillInsertText()` keep handling inserting remaining text
with non-positioned `EditorDOMPoint`. Therefore, at the next time,
`WSRunObject` fails to do anything since it requires positioned
`EditorDOMPoint`.
For making uplift safer, this patch makes `WSRunObject::InsertText()` set
`aPointAfterInsertedString` by itself when
`HTMLEditor::InsertTextWithTransaction()` returns error.
Differential Revision: https://phabricator.services.mozilla.com/D32131
--HG--
extra : moz-landing-system : lando
`GetInternalCommand()` is currently used only by `EditorCommand` and it
treats the additional parameter only when given command is `cmd_align`.
However, the value is complicated since `AlignCommand` allows both `CString`
value and `String` value. Therefore, `EditorCommand::DoCommandParams()` may
fail to solve `cmd_align` to a `Command` value without checking both of them.
Therefore, it must make sense that `GetInternalCommand()` take `nsCommandParams`
as optional argument and check it only when given command matches `cmd_align`.
Then, we don't need to waste unnecessary run-time cost.
Note that this bug has been hidden since `AlignCommand` class does not refer
the `Command` value but refers only `nsCommandParams`. However, the previous
patch makes `EditorCommand::GetParamType()` not allow `Command::DoNothing`.
Therefore, we need this follow-up fix now.
Differential Revision: https://phabricator.services.mozilla.com/D30501
--HG--
extra : moz-landing-system : lando
If `nsIControllerCommand::DoCommandParams()` is called without aParams or
`nsITransferable` pointer, this patch sets nullptr to `aTransferableParam` for
`DoCommandParam()`. This allows each implementation to choose ignore or
return error.
Differential Revision: https://phabricator.services.mozilla.com/D30500
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--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
This seems to be regression by bug 1362858.
Actually, single quotation mark is always separator for spellchecker after
landing bug 1462858. When user tries to input "doesn't", "'" becomes separator
for spellchecker. Then "doesn" will be misspell word.
So we shouldn't mark single quotation mark as separator if user is inputting
word.
Differential Revision: https://phabricator.services.mozilla.com/D29153
--HG--
extra : moz-landing-system : lando
It'd be better to change copy constructor of `EditorDOMPointBase` to explicit,
but it'd require too many changes in editor code. So, this patch just changes
each method callers only.
Differential Revision: https://phabricator.services.mozilla.com/D30054
--HG--
extra : moz-landing-system : lando
For guaranteeing the sets of container node, offset in it, and the node
referred by the offset, the method should use `EditorDOMPoint` instead of
managing them separately.
Differential Revision: https://phabricator.services.mozilla.com/D30015
--HG--
extra : moz-landing-system : lando
This is a simple mistake of `MOZ_ASSERTION()` in it. When `mParent` is a node
which can have children, `mChild` should be non-`nullptr` or `mOffset` should
/ be set to the end of `mParent`. But when `mParent` is not a container, any
`mOffset` value should be allowed.
Differential Revision: https://phabricator.services.mozilla.com/D30014
--HG--
extra : moz-landing-system : lando
As far as I've tested, `TextEditor` has the following structure patterns:
1. If it's for a non-empty `<input>` element, it has only one text node.
2. If it's for an empty `<input>` element, it has only bogus node.
3. If it's for a non-empty `<textarea>` element, it has a text node and
`moz-<br>` element. Additionally they are followed by `<scrollbar>` and
`<resizer>` elements.
4. If it's for an empty `<textarea>` element, it has a `moz-<br>` element
followed by `<scrollbar>` and `<resizer>` elements.
Additionally, `TextEditRules::WillInsert()` always removes bogus node if
there is. So, in the case #2, there is no children.
Fortunately, we don't support XUL addons anymore on Firefox. However, in
other products like Thunderbird, the tree may be changed as unexpected.
Therefore, we still need to keep checking the tree, but we can use the fast
path for `<textarea>` element too.
Differential Revision: https://phabricator.services.mozilla.com/D30012
--HG--
extra : moz-landing-system : lando
This patch makes editors return new error code internally when clipboard event
is dispatched and canceled by script. This is for making each caller stop
handling the edit action. However, it's not actual failure. Therefore, making
public methods return `NS_SUCCESS_DOM_NO_OPERATION` instead via
`EditorBase::ToGenericNSResult()`.
Differential Revision: https://phabricator.services.mozilla.com/D28935
--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
And also this patch moves some related methods which use the inline methods
and member variables used only by them.
Differential Revision: https://phabricator.services.mozilla.com/D29201
--HG--
rename : layout/base/nsIPresShellInlines.h => layout/base/PresShellInlines.h
extra : moz-landing-system : lando
A test was intermittently crashing because it was calling
restoreNormalRefresh after closing the window. This meant
LayerTransactionParent::RecvLeaveTestMode fired after the
CompositorBridgeParent had been destroyed.
This fixes the test by calling restoreNormalRefresh before
win.close. It also checks mDestroyed in RecvLeaveTestMode (for both
LayerTransactionParent and WebRenderBridgeParent).
Differential Revision: https://phabricator.services.mozilla.com/D29228
--HG--
extra : moz-landing-system : lando
fixed editor/libeditor mochitests to work outside of isolated clipboard job.
Differential Revision: https://phabricator.services.mozilla.com/D28837
--HG--
extra : moz-landing-system : lando
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
--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
This patch makes all editor command classes derived from `EditorCommand` class.
So, this allows `nsHTMLEditor::ExecCommand()` to access them directly in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D28683
--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
`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
Moved mozilla::WidgetMosueEventBase::buttonType in MouseEvents.h to mozilla::MouseButton in EventForwards.h, and mozilla::WidgetMouseEventBase::buttonsFlag to mozilla::MouseButtonsFlag so that any referer in header files do not need to include MouseEvents.h only for referring them. Instead, they just need to include EventForwards.h. Now when MouseEvents.h is changed, the rebuild speed becomes faster.
Differential Revision: https://phabricator.services.mozilla.com/D25325
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::button to WidgetMouseEventBase::mButton.
Differential Revision: https://phabricator.services.mozilla.com/D25309
--HG--
extra : moz-landing-system : lando
The attributes for an interface should be on the line right before the
interface.
Interface attributes should be separated by spaces.
Clean up some trailing whitespace in widget/.
Differential Revision: https://phabricator.services.mozilla.com/D28234
--HG--
extra : moz-landing-system : lando
Editable elements will no longer get click events for non-primary mouse buttons
since they are being unshipped from the web in favour of auxclick events.
Listen for auxclick as well so middle-click paste still works.
Don't stop propagation after middle-click paste, instead ignore clicks on
contenteditable elements in ClickHandlerChild.
Update test_middle_click_paste.html for the new behaviour.
Also remove the mNoContentDispatch overrides in HTMLInputElement and
HTMLTextAreaElement that were needed for middle-pasting.
Differential Revision: https://phabricator.services.mozilla.com/D26792
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--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
Different from the comment in `EditorCommands.h`, editing commands and
editor commands are instantiated for each editable document or each
`HTMLInputElement` or `HTMLTextareaElement`. Therefore, even though they
are stateless, we allocate too many instances of them. We should make
them singleton classes to reduce the footprint and save runtime allocation
cost.
Differential Revision: https://phabricator.services.mozilla.com/D27406
--HG--
extra : moz-landing-system : lando
So, this patch makes all caller of it safe including its arguments unless
they come from other methods.
Differential Revision: https://phabricator.services.mozilla.com/D27225
--HG--
extra : moz-landing-system : lando
This patch makes `nsDocShell::GetPresShell()` and
`nsDocShell::GetEldestPresShell()` return `mozilla::PresShell*` and
some non-public methods use `mozilla::PresShell*` directly.
Differential Revision: https://phabricator.services.mozilla.com/D26424
--HG--
extra : moz-landing-system : lando
`mozSpellChecker::Replace` and `mozSpellChecker::NextMisspelledWord` have a loop
to find word from text content. But `mozEnglishWordUtils::FindNextWord` always
returns `NS_OK` and some code doesn't check error even if `nsresult` local
variable is used.
So I would like to clean up this loop.
- `mozEnglishWordUtils::FindNextWord` should return true if word is found
- We should use reference type for some `TextServicesDocument`'s methods.
- Add more check for error
Differential Revision: https://phabricator.services.mozilla.com/D27037
--HG--
extra : moz-landing-system : lando
If insertion string ends with ASCII whitespace and there is no following
content in the block, `HTMLEditRules::AdjustWhitespaces()` needs to insert
`<br>` element. It's called only by `HTMLEditRules::AfterEditInner()` and
that does only simple things with `WSRunObject`. Therefore, this moves the
code into `AfterEditInner()`.
For making it adjust the whitespaces, `HTMLEditRules::WillInsertText()` needs
to notify `AfterEditInner()` of dirty range with `mDocChangeRange`. Therefore,
this patch makes it set `mDocChangeRange` manually after inserting composition
string.
On the other hand, there is another bug. `WSRunObject` was designed to treat
only inserting text for `WSRunObject::InsertText()`. I.e., not designed to
treat replacing existing composition string with new string. Therefore,
`WSRunObject::InsertText()` adjusts whitespaces only around start of
composition string. Therefore, if composition string ends with an ASCII
whitespace, it's not replaced with NBSP and that causes:
- failing `WSRunObject::AdjustWhitespaces()` inserts `<br>` element at
`AfterEditInner()` of committing composition.
- then, next composition's first `WSRunObject::InsertText()` removes the
last whitespace due to not followed by `<br>` nor any other content.
Therefore, this patch makes `WSRunObject` takes 2 DOM points to be able to
treat replaced range.
In strictly speaking, the latter change require more changes and tests for
supporting replacement with any other methods. However, it's risky and out
of scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D26423
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
`nsPICommandUpdater` is a scriptable interface, but nobody refers it from JS,
and it's implemented only by `nsCommandManager`. Therefore, we can get rid
of this interface.
Additionally, `nsCommandManager::Init()` is called only by `nsDocShell`, which
is the only instantiater of the class, and returns error only when given window
is nullptr. Therefore, we can make the constructor take the window instead.
Differential Revision: https://phabricator.services.mozilla.com/D25729
--HG--
extra : moz-landing-system : lando
`nsIControllerCommandTable` isn't implemented with JS even in comm-central nor
BlueGriffon. Therefore, we can make it a builtinclass.
Additionally, it's inherited only by nsControllerCommandTable. So, all users
in C++ can treat the concrete class directly.
Differential Revision: https://phabricator.services.mozilla.com/D25727
--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
This is the last step to be able to call matchMedia on display: none iframes.
This is green, except for some startup preference query tests that I'm going to
address in a blocking bug (making LangGroupFontPrefs global, basically).
The setup is similar to the ShadowRoot one, except we don't eagerly keep the
StyleSet around up-to-date, we only fill it if it ever had a pres context.
Differential Revision: https://phabricator.services.mozilla.com/D23903
--HG--
extra : moz-landing-system : lando
If user disables clipboard events, it means that they don't want to expose
clipboard data to web apps even if web apps cannot handle "paste" operation.
Therefore, they must not want to leak clipboard data with `InputEvent.data`
and `InputEvent.dataTransfer`.
This patch makes `InputEvent::GetData()` and `InputEvent::GetDataTransfer()`
returns empty string or new `DataTransfer` object which has only empty string
if:
- They are called by content JS.
- The event is a trusted event.
- `inputType` value is `insertFromPaste` or `insertFromPasteAsQuotation`.
The reason why we don't return null for both is, Input Events spec declares
`data` or `dataTransfer` shouldn't be null in the `inputType` values. And
the reason why we don't return empty `DataTransfer` is, web apps may expect
at least one data is stored in non-null `dataTransfer` value.
Differential Revision: https://phabricator.services.mozilla.com/D25350
--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 makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--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
No one (m-c, c-c and bluegriffon) uses nsIPlaintextEditor.setWrapColumn from
script. It is used from C++ only.
Differential Revision: https://phabricator.services.mozilla.com/D25363
--HG--
extra : moz-landing-system : lando
`Selection::Extend()` is too slow but editor and ContentEventHandler use it in
some places. We should make them use `Selection::SetStartAndEndInLimiter()` or
`Selection::SetBaseAndExtentInLimiter()`. The former is usable only when caller
guarantees the start point is prior to the end point in the DOM tree.
Otherwise, we need to use the latter even though it's slower than the former.
Differential Revision: https://phabricator.services.mozilla.com/D23462
--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
`Selection::Extend()` is too slow because:
- it may create some `nsRange` instances.
- it users `nsContentUtils::ComparePoints()` multiple times.
Therefore, we can improve the performance if we can stop using it in some
places. First, this patch creates `Selection::SetStartAndEnd()` and
`Selection::SetStartAndEndInLimiter()` for internal use. They remove
current ranges, reuse `nsRange` instance as far as possible and add new
range which is set by their arguments. Then, this patch makes
`Selection::SelectAllChildren()` stop using `Selection::Extend()`. At this
time, this fixes a web-compat issue. `Selection::Expand()` cannot cross the
selection limiter boundary when there is a limiter (e.g., when an editing host
has focus). But we can now fix this with using the new internal API.
Note that methods in editor shouldn't move selection to outside of active
editing host. Therefore, this patch adds `Selection::SetStartAndEndInLimiter()`
and `Selection::SetBaseAndExtentInLimiter()` for them.
Differential Revision: https://phabricator.services.mozilla.com/D23459
--HG--
extra : moz-landing-system : lando
Actually, we only support `text/unicode` mime type on Android clipboard backend. But Android API 16+ supports `text/html`, so we should support this type since Chrome/Blink already supports it.
Differential Revision: https://phabricator.services.mozilla.com/D22659
--HG--
extra : moz-landing-system : lando
`Selection::Extend()` is too slow but editor and ContentEventHandler use it in
some places. We should make them use `Selection::SetStartAndEndInLimiter()` or
`Selection::SetBaseAndExtentInLimiter()`. The former is usable only when caller
guarantees the start point is prior to the end point in the DOM tree.
Otherwise, we need to use the latter even though it's slower than the former.
Differential Revision: https://phabricator.services.mozilla.com/D23462
--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
`Selection::Extend()` is too slow because:
- it may create some `nsRange` instances.
- it users `nsContentUtils::ComparePoints()` multiple times.
Therefore, we can improve the performance if we can stop using it in some
places. First, this patch creates `Selection::SetStartAndEnd()` and
`Selection::SetStartAndEndInLimiter()` for internal use. They remove
current ranges, reuse `nsRange` instance as far as possible and add new
range which is set by their arguments. Then, this patch makes
`Selection::SelectAllChildren()` stop using `Selection::Extend()`. At this
time, this fixes a web-compat issue. `Selection::Expand()` cannot cross the
selection limiter boundary when there is a limiter (e.g., when an editing host
has focus). But we can now fix this with using the new internal API.
Note that methods in editor shouldn't move selection to outside of active
editing host. Therefore, this patch adds `Selection::SetStartAndEndInLimiter()`
and `Selection::SetBaseAndExtentInLimiter()` for them.
Differential Revision: https://phabricator.services.mozilla.com/D23459
--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
Summary: Actually, we only support `text/unicode` mime type on Android clipboard backend. But Android API 16+ supports `text/html`, so we should support this type since Chrome/Blink already supports it.
Reviewers: #geckoview-reviewers, snorp
Reviewed By: #geckoview-reviewers, snorp
Bug #: 676268
Differential Revision: https://phabricator.services.mozilla.com/D22659
--HG--
extra : rebase_source : 17ef0aa06b83b812bb9bccfab93a72e0b37f9652
Firefox, comm-central and bluegriffon don't use `*JSAndPlugin*` methods of
`nsIEditingSession` from script. Let's remove or move to `nsEditingSession`.
Differential Revision: https://phabricator.services.mozilla.com/D22465
--HG--
extra : rebase_source : 256fb4025fe8c6f5a61d5b015af942ff65759c23
Only Firefox has an operation to paste clipboard data as quoted text
(Control + middle button paste). Input Events Level 1 and Level 2 declared
new inputType value for this operation. Therefore, we should support it.
Differential Revision: https://phabricator.services.mozilla.com/D22067
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
Accidentally, I removed the check in the previous landing (bug 1529190). This
patch restores it.
Differential Revision: https://phabricator.services.mozilla.com/D20970
--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
We should stop handling splitting nodes if mutation event listeners move or
remove the split nodes unexpectedly because the post processors may not be
able to keep handling the nodes. For example, if a node is moved to outside
of editing host, we shouldn't touch it anymore due to non-editable.
This patch makes `EditorBase::DoSplitNode()` return new error for making
any parent callers stop their job, but note that the following patch makes
any public methods expose the new error as exception for compatibility with
Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D20810
--HG--
extra : moz-landing-system : lando
Oddly, `SplitNodeTransaction::DoTransaction()` checks the result of
`EditorBase::DoSplitNode()` only when it's not allowed to change `Selection`.
We should make it always check the result.
Differential Revision: https://phabricator.services.mozilla.com/D20809
--HG--
extra : moz-landing-system : lando
`InsertTagCommand::DoCommandParams()` inserts given URL to `href` of `<a>` or
`src` of `<img>`. However, it treats the given URL includes only ASCII
characters. Therefore, we cannot insert URL including non-ASCII characters
with `execCommand("createLink")` nor `execCommand("insertImage")`.
This patch makes `nsHTMLDocument::ExecCommand()` set the param as `nsString`
and makes `InsertTagCommand::DoCommandParams()` retrieve it with `GetString()`.
Differential Revision: https://phabricator.services.mozilla.com/D20615
--HG--
extra : moz-landing-system : lando
`InsertTagCommand::DoCommandParams()` uses `Element::SetAttribute()` which takes
`nsAString` as attribute name. For avoiding unnecessary copy of attribute name,
we should make it use `Element::SetAttr()` which takes `nsAtom` instead.
Differential Revision: https://phabricator.services.mozilla.com/D20614
--HG--
extra : moz-landing-system : lando
"cmd_copyAndCollapseToEnd" is referred only by CopyPasteAssistent (even
including comm-central and BlueGriffon), but CopyPasteAssistent won't receive
"copy" command to send it.
So, it seems that we can get rid of a lot around CopyPasteAssistent but this
patch just changes the mapping in it ("copy" is mapped to "cmd_copy") and
removes command handlers of "cmd_copyAndCollapseToEnd" completely.
Differential Revision: https://phabricator.services.mozilla.com/D20612
--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
"cmd_clearUndo" 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, ClearUndoCommand.
Differential Revision: https://phabricator.services.mozilla.com/D20610
--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
This code was already handling the world going away, but did not handle the case
of just getting unbound, which can happen if some selection listener (e.g.,
AccessibleCaret) flushes layout.
Differential Revision: https://phabricator.services.mozilla.com/D20469
--HG--
extra : moz-landing-system : lando
Only nsBlockFrame and its subclasses recognize the nsIFrame::eBlockFrame
flag, so we can replace the usage of the flag with either
nsIFrame::IsBlockFrameOrSubclass() or a do_QueryFrame().
Differential Revision: https://phabricator.services.mozilla.com/D20542
--HG--
extra : moz-landing-system : lando
Even less so on reframe, where it's just unsound to do so. I had to give a value
to eSetValue_Internal, since otherwise I cannot check for its presence. I can
further special-case the reframe case if you prefer.
Differential Revision: https://phabricator.services.mozilla.com/D20133
--HG--
extra : moz-landing-system : lando
DataTransfer should have more 2 constructors. One takes |const nsAString&| and
sets its data to the string. The other takes |nsITransferable*| and stores only
its data with DataTransferItem.
If given data is external resource like the case of `HTMLEditor::PasteTransferable()`,
we should copy its data to each DataTransferItem because nsITransferable is not
cycle-collectable, but DataTransfer may be grabbed by JS. Unfortunately, adding
new path to initialize DataTransfer with nsITransferable instance is too risky
because DataTransfer and DataTransferItem work together to initialize each of
them if DataTransfer is in external mode. Therefore, this patch makes the
new constructor temporarily sets it to in external mode, then, cache usable types
first, then, call `FillAllExternalData()` to make each DataTransferItem initializes
its data by itself, finally, make the constructor set it to internal mode and release
nsITransferable instance. This is ugly implementation but the most reasonable
way for now because:
- We don't need to change DataTransfer nor DataTransferItem a lot in this bug.
- We don't need to duplicate any code like a loop in `CacheExternalData()`.
In another bug, we should redesign DataTransfer and DataTransferItem to
make DataTransferable easier to be added new constructors.
Differential Revision: https://phabricator.services.mozilla.com/D19298
--HG--
extra : moz-landing-system : lando
InputEvent.dataTransfer should be set to non-null when InputEvent.inputType
is "insertFromPaste", "insertFromDrop" or "insertReplacementText" and
editor is an HTMLEditor instance:
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://w3c.github.io/input-events/#dfn-data
("insertTranspose" and "insertFromYank" are not currently supported on Gecko.)
This patch makes nsContentUtils::DispatchInputEvent() take dataTransfer value
and EditorBase set it via AutoEditActionDataSetter like data value.
However, we need to create other constructors of DataTransfer to create its
read-only instances initialized with nsITransferable or nsAString. This will
be implemented by the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D19297
--HG--
extra : moz-landing-system : lando
Although neither Chrome nor Safari does not set InputEvent.data when the event
is caused by `document.execCommand()` with `backColor`, `foreColor` nor
`hiliteColor`, Safari supports styling color with touchbar and in that case,
Safari sets it (*1).
Additionally, currently Safari uses `rgb()` to represents a color value and
using same rule to serializing color value for CSS OM matches Safari's behavior
and can represent any valid color values.
This patch makes given color value parsed and then serialized with same code
in style system. If the value is `currentcolor`, `inherit`, `initial` or `reset`, sets
the value as-is for now. Additionally, when given value is invalid, sets the value
as-is for forward compatibility.
Note that automated tests will be added into input-events-exec-command.html
by the last patch.
1. https://github.com/w3c/input-events/issues/94#issuecomment-461061517
Differential Revision: https://phabricator.services.mozilla.com/D19295
--HG--
extra : moz-landing-system : lando
Although neither Chrome nor Safari does not set InputEvent.data value when
InputEvent.inputType is "fontName", but it's easy to implement. Therefore, this
patch implements it as declaration of Input Events.
This patch uses given value as-is. Perhaps, this shouldn't cause any problems
because such value can be set to Element.style.fontFamily without any changes.
Note that automated test will be added into WPT later.
Differential Revision: https://phabricator.services.mozilla.com/D19294
--HG--
extra : moz-landing-system : lando
Although neither Chrome nor Safari does not set InputEvent.data value when
InputEvent.inputType is "insertLink", but it's easy to implement. Therefore,
this patch implements it as declaration of Input Events.
This patch sets the value to raw href attribute value because we create
<a> element without absolute URI when web apps call execCommand("createLink")
with relative URI.
Differential Revision: https://phabricator.services.mozilla.com/D19291
--HG--
extra : moz-landing-system : lando
When InputEvent.inputType is "formatSetBlockTextDirection" or
"formatSetInlineTextDirection", InputEvent.data value should be one of
"ltr", "rtl", "auto" or "null".
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://w3c.github.io/input-events/#dfn-data
We only supports "ltr" and "rtl" when user switches the direction with
Accel + Shift + X. Therefore this patch makes EditorBase set the data
to "ltr" or "rtl".
Oddly, with synthesizing the shortcut keys, the command is not executed
properly in the automated test. Therefore, this patch dispatches the
command directly.
Differential Revision: https://phabricator.services.mozilla.com/D19288
--HG--
extra : moz-landing-system : lando
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://w3c.github.io/input-events/#dfn-data
Both Input Events Level 1 and Level 2 declare that InputEvent.data should be
set to inserting string only on TextEditor when InputEvent.inputType is
"insertFromPaste", "insertFromPasteAsQuotation", "insertFromDrop",
"insertTranspose", "insertReplacementText" or "insertFromYank".
Currently, we support only "insertFromPaste", "insertFromDrop",
"insertReplacementText". Therefore, this patch makes TextEditor set
EditorBase::mEditActionData::mData only for them (and the instance is not
HTMLEditor's).
Differential Revision: https://phabricator.services.mozilla.com/D19287
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
No one uses CheckCurrentWordNoSuggest. So I would like to get a rid of this
method. And this method is only user of mozSpellChecker::CheckWord. So
mozSpellChecker::CheckWord shouldn't allow that aSuggestions is nullptr on
content process since we already have async API as mozSpellChecker::CheckWords.
Differential Revision: https://phabricator.services.mozilla.com/D19303
--HG--
extra : moz-landing-system : lando
Summary:
Editor changes caret visibility during drag and drop. But when destroying
editor, we don't restore caret state. So we should restore it when destroying
editor.
Tags: #secure-revision
Bug #: 1496118
Differential Revision: https://phabricator.services.mozilla.com/D18923
--HG--
extra : rebase_source : 157f2c9e69857c7f7adb916af2a319392c4d125a
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
GitLab's comment calls scrollTop on input event handler. The scollTop may cause
reflow. When causing reflow, editor is destroyed and initialized again. Then
nsTextEditorState will set current value to editor. But this is failure.
By bug 1465702, selection is cached in edit action. When initializing editor,
selection controller is updated, so selection into cache becomes invalid. It
means that all selection methods will return error since document is different.
So we should update selection cache when initializing editor.
Also, I cannot create test case for this situation since we have to cause reflow
in input and/or composition event. Do you have any idea?
Differential Revision: https://phabricator.services.mozilla.com/D16944
--HG--
extra : moz-landing-system : lando
For mozInlineSpellChecker, I would like to add promse-based method to check
word. But this method is
- On content process, it works by async.
- On chrome process, it works by sync.
Some reftests with non-e10s don't wait that spellchecker is finished correctly
due to race condition of spellchecker dictionary update. So it uses sync'd
promise on chrome.
Differential Revision: https://phabricator.services.mozilla.com/D14836
--HG--
extra : rebase_source : 63d8fb1b3a6f8754f5b7604ea920c1a26bcd4f5b
