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
Masayuki Nakano
Sylvestre Ledru
Joel Maher
Jamie Nicol
Ryan Hunt
Andreea Pavel
Daniel Varga
Razvan Maries
Srujana Peddinti
Andrew McCreight
Ian Moody
Brian Grinstead
Makoto Kato
Cosmin Sabou
Emilio Cobos Álvarez
Csoregi Natalia
Brindusan Cristian