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
Victor Porof
Razvan Maries
Rob Wu
Mirko Brodesser
Mihai Alexandru Michis
Brendan Dahl
Kris Maglione
Masayuki Nakano
Ciure Andrei
Narcis Beleuzu
Jonathan Kingston
Boris Zbarsky
Makoto Kato
Emilio Cobos Álvarez
Ehsan Akhgari
Bogdan Tara
Sylvestre Ledru
Brindusan Cristian
arthur.iakab