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
For making the scope of variants clearer, make it use `let` instead of `var`.
Differential Revision: https://phabricator.services.mozilla.com/D37057
--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
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
Amend several test files for triggering eval() assertion through simpletest.js
Differential Revision: https://phabricator.services.mozilla.com/D30474
--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
The iframe test runs on an cross-docgroup iframe, even though chrome JS can
observe it in this test.
This test is relying on the getBoundingClientRect() call below in order to flush
the parent document layout as well, but that's going to stop happening (see the
bug and patch).
Differential Revision: https://phabricator.services.mozilla.com/D28302
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
This is closer to what other UAs do, it's simpler, and fixes the bug.
It looks like the complexity of multiple buttons or what not is related to
bug 1188880, which is WONTFIX. We no longer have multiple buttons in the same
file input, so this is better IMO.
Differential Revision: https://phabricator.services.mozilla.com/D26825
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
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--HG--
extra : moz-landing-system : lando
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--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
***
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
This prevents mouse events from firing on browsers in unfocused windows. It used to be done
with the [clickthrough=never] attribute set from XBL content.
Differential Revision: https://phabricator.services.mozilla.com/D16498
--HG--
extra : moz-landing-system : lando
This patch implements InputType.inputType which is declared by Input Events.
The attribute has already been implemented by Chrome and Safari. Chrome
implements Input Events Level 1, but Safari implements Input Events Level 2.
Difference between them is only whether it supports "insertFromComposition",
"deleteByComposition" and "deleteCompositionText". This patch makes the
level switchable with pref and takes Level 1 by default because Level 2 is
still unstable around event order with composition events.
For reducing string copy cost at dispatching "input" event, this patch
makes EditorInternalInputEvent store valid input-type as enum class,
EditorInputType and resolves it to string value when
dom::InputEvent::GetInputType() is called. Note that the reason why
this patch names the enum class as EditorInputType is, there is InputType
enum class already for avoiding conflict the name, this appends "Editor"
prefix because "input" and "beforeinput" events are fired only when an
editor has focus.
Differential Revision: https://phabricator.services.mozilla.com/D14128
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
The usage of our specific "text" event is enough low (0.0003%). So, let's
stop dispatching the event in the default group of web content. Once we
release this new behavior, we can get rid of dispatching the event even in
chrome. Then, we can optimize the event order for new specs.
Differential Revision: https://phabricator.services.mozilla.com/D13034
--HG--
extra : moz-landing-system : lando
It's difficult to create new test which checks "input" events caused by
all edit operations especially when text is inserted from our UI. Therefore,
this adds "input" event type checks into existing tests.
Additionally, this adds new test for MozEditableElement.setUserInput() whose
behavior needs to be fixed in this bug.
Currently, InputEvent interface should be used only on text controls or
contenteditable editor when dispatching "input" event.
https://w3c.github.io/input-events/#events-inputevents
You may feel odd to use different event interface for same "input" events.
However, other browsers also use InputEvent interface only in the cases. So,
we should follow them for now.
Differential Revision: https://phabricator.services.mozilla.com/D12243
--HG--
extra : moz-landing-system : lando
