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
Before this change, only elements inside the shadow root tree were scanned for the
draggable=true attribute. We now check the flattened tree instead so an element
inside a shadow root can start a drag for an element containing the shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D30365
--HG--
extra : moz-landing-system : lando
If needed for web-compat.
Also stop dispatching auxclicks if non-primary click has been preventDefaulted,
so that legacy new-tab prevention can work with the pref flip.
Differential Revision: https://phabricator.services.mozilla.com/D27364
--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
- `Array.map` becomes `Array.from`
- Array copying via `Array.slice` becomes `Array.from`.
- `Array.forEach` that did not rely on closures becomes `for`-`of` loops.
- Anything else: `Array.X` becomes `Array.prototype.X`.
Complex cases:
dom/bindings/test/TestInterfaceJS.js and
dom/bindings/test/test_exception_options_from_jsimplemented.html
use `Array.indexOf` to generate an error with a specific error message.
Switched to `Array.prototype.forEach` to generate the same error.
js/src/jit-test/tests/basic/exception-column-number.js
In this test `Array.indexOf()` is used to generate an error. Since the
exact message doesn't matter, I switched to `Array.from()`.
Intentionally not changed:
editor/libeditor/tests/browserscope/lib/richtext/richtext/js/range.js
Did not modify because this is 3rd-party code and the code uses
feature detection as a fall back when Array generics are not used.
testing/talos/talos/tests/dromaeo/lib/mootools.js
Did not modify because mootools adds the `Array.slice` method to the
`Array` object.
Not changed because they check the implementation of Array generics:
js/src/jit-test/tests/basic/arrayNatives.js
js/src/jit-test/tests/basic/bug563243.js
js/src/jit-test/tests/basic/bug618853.js
js/src/jit-test/tests/basic/bug830967.js
js/src/jit-test/tests/jaeger/recompile/bug656753.js
js/src/jit-test/tests/self-hosting/alternate-static-and-instance-array-extras.js
js/src/tests/non262/Array/generics.js
js/src/tests/non262/Array/regress-415540.js
js/src/tests/non262/extensions/regress-355497.js
js/src/tests/non262/extensions/typedarray-set-neutering.js
Depends on D27802
Differential Revision: https://phabricator.services.mozilla.com/D27803
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ 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/D27457
--HG--
extra : moz-landing-system : lando
By adding a third target instead of waiting to see if the mouse has gone out of
scope in order to assert that we haven't fired mouseleave on the host.
Differential Revision: https://phabricator.services.mozilla.com/D25628
--HG--
extra : moz-landing-system : lando
In normal cases, `PresShell::EventHandler` won't receive untrusted event.
However, only `nsIDOMWindowUtils.dispatchDOMEventViaPresShell()` may send
untrusted event if its `aTrusted` is false. Currently, this is not used by
chrome so that we don't need to keep supporting it for dispatching untrusted
events.
This patch removes `aTrusted` argument from it.
Differential Revision: https://phabricator.services.mozilla.com/D24870
--HG--
extra : moz-landing-system : lando
Hiding document.createEvent("TouchEvent"), document.createTouch, document.createTouchList and ontouch* event
handlers on desktop to follow what Chrome has done.
This patch explicitly does not remove createTouch or createTouchList everywhere, although those seem to have been
removing already on some other browsers.
Devtools use TOUCHEVENTS_OVERRIDE_ENABLED for touch event testing, and this patch keeps the old behavior per discussion
with devtools devs.
Differential Revision: https://phabricator.services.mozilla.com/D22081
--HG--
extra : rebase_source : 562588a289632ba2f11db7f3ac8782c26c3b05f8
InputEvent.dataTransfer is declared by Input Events Level 1 and Level 2 (i.e.,
not UI Events). It's necessary for "beforeinput" event on contenteditable
elements because of with some InputEvent.inputType values on contenteditable,
InputEvent.dataTransfer is used instead of InputEvent.data.
According to the Chrome's behavior, if InputEvent.dataTransfer is created by
web apps, the DataTransfer object is mutable. Otherwise, i.e., the event
represents user input, the DataTransfer object is read only. We should follow
this behavior.
This is enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D19296
--HG--
extra : moz-landing-system : lando
InputEvent.data notifies web apps of inserting/inserted text with "beforeinput"
and "input" events. So, this is important especially for "beforeinput" event
listeners. That's the reason why we need to support this before implementing
"beforeinput" event.
This patch adds it into InputEvent and make it enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D19285
--HG--
extra : moz-landing-system : lando
re-enable many tests on windows 1803 due to invalid screen resolution whilst testing
Differential Revision: https://phabricator.services.mozilla.com/D19535
--HG--
extra : moz-landing-system : lando
When preceding mouse event is handled, that may cause changing style of the
target. Therefore, when an eMouseDown or eMouseUp event is handled, handlers
require the latest layout. Currently, nsViewManager::DispatchEvent() tries
to guarantee that with calling nsIPresShell::FlushPendingNotifications()
with FlushType::Layout. However, this just flushes the pending layout in
the PresShell associated with the nsViewManager instance. I.e., if the
target is in a child PresShell, its layout hasn't been flushed.
This patch makes PresShell::EventHandler::HandleEvent() flush pending
notifications at first of handling events using coordinates (only when
eMouseDown or eMouseUp, though). Then, when it realizes that the event
should be handled in a child PresShell, makes it flush its pending
notifications and then, recompute event target with the latest layout if
the layout is actually changed.
Differential Revision: https://phabricator.services.mozilla.com/D13720
--HG--
extra : moz-landing-system : lando
With these changes, XBL just runs in the window scope of whatever document it's
attached to. Since (outside of tests and "remote XUL") we no longer attach XBL
to web documents, this is fine. And "remote XUL" already ran without the XBL
scope.
Native anonymous content, which used to be placed in the XBL scope to hide it
from the page, is now placed in the unprivileged junk scope, so it stays hidden
from the page.
dom/xbl/test/test_bug944407.xul is being removed because we are changing the
behavior it's trying to test for. Since we now always put the XBL in the same
scope as the page, script is enabled for the XBL if and only if it's enabled for
the page.
dom/base/test/test_bug419527.xhtml, dom/events/test/test_bug391568.xhtml,
dom/xbl/test/test_bug1086996.xhtml are being switched to a chrome test because
otherwise the XBL can't see the getAnonymousNodes method.
All the XBL bits are being removed from test_interfaces because we no longer
have a separate XBL scope to test the behavior of.
js/xpconnect/tests/mochitest/test_nac.xhtml is being removed because XBL no
longer has access to NAC unless the page it's attached to does too, so the test
doesn't really make sense.
layout/xul/test/test_bug1197913.xul is being switched to a chrome test because
its XUL elements use bindings that rely on APIs that are not exposed to normal
web content.
layout/reftests/bugs/495385-2f.xhtml is being removed because I can't think of
a sane way to test that in the new world, short of running the reftest as
chrome. And it doesn't seem worthwhile to look for a way to do that.
dom/xbl/test/test_bug1098628_throw_from_construct.xhtml now needs to
expectUncaughtException(), because the exception is now being thrown in Window
scope.
dom/xbl/test/test_bug1359859.xhtml needs to expectUncaughtException() as needed
and not use XPCNativeWrapper (which it doesn't need to anyway now).
dom/xbl/test/test_bug389322.xhtml, dom/xbl/test/test_bug400705.xhtml,
dom/xbl/test/test_bug401907.xhtml, dom/xbl/test/test_bug403162.xhtml,
dom/xbl/test/test_bug526178.xhtml, dom/xbl/test/test_bug639338.xhtml don't need
to use XPCNativeWrapper anymore.
dom/xbl/test/test_bug821850.html is being removed because it exists only to test XBL scopes.
dom/xbl/test/file_bug950909.xml is being changed to work without a separate XBL
scope (though whether the test still makes sense at that point is a bit questionable).
Differential Revision: https://phabricator.services.mozilla.com/D19260
--HG--
extra : moz-landing-system : lando
Old Confluence does not aware of conflated model keypress event (see UI Events
spec, https://w3c.github.io/uievents/#determine-keypress-keyCode).
Additionally, Confluence can be hosted with any domains. Therefore, we cannot
use blacklist to disable the conflated model keypress event only on it.
This patch checks whether current or parent document is Confluence with JS
module, called KeyPressEventModelCheckerChild. For kicking this module,
nsHTMLDocument dispatches an custom event, CheckKeyPressEventModel, when it
becomes editable only first time. Finally, if it's a Confluence instance, the
module let PresShell know that we need to use split model keypress event in it.
Differential Revision: https://phabricator.services.mozilla.com/D17907
--HG--
extra : moz-landing-system : lando
