The test case uses double intervals to make sure there is enough time to wait for the scroll event before continuing the testing. However, it doesn't work while the first timeout is delayed and the second one isn't. Tweaked the test case to start the second timer when the first one timeout.
MozReview-Commit-ID: gvhtIpzauE
This patch declares a new default action, "horizontal scroll", this scrolls
content horizontally with deltaY of wheel events and ignores deltaX and deltaZ.
This is used for default action with Shift key in default setting except on
macOS. On macOS, legacy mouse's vertical wheel operation with Shift key causes
native horizontal wheel event. Therefore, we don't need to use this new
default action on macOS. Additionally, old default action with Shift key,
navigating history, is moved to with Alt key. This makes same settings between
macOS and the others. So, this is better for users who use macOS and another
OS and web app developers who check wheel events only on macOS or other
platform(s).
For simpler implementation, default action handlers moves deltaY values to
deltaX values temporarily *only* while they handle wheel events. This is
performed by AutoWheelDeltaAdjuster and restored after handling it
automatically.
So, in other words, even if default action is "horizontal scroll", web apps
receives wheel events whose deltaY is not zero but its content will be
scrolled horizontally. This is same as Chromium, so, this behavior shouldn't
cause any incompatible behavior with it.
MozReview-Commit-ID: E4X3yZzLEAl
--HG--
extra : rebase_source : e20d854c6b0a181ad4c9e7304bd9ad14256481ff
Spec says we should throw an exception when setting pointer capture while the page has a locked element. Also, we should release all pointer capture when a pointer lock is successfully applied on an element.
MozReview-Commit-ID: CuUIPipJWB0
This isn't a super essential feature, and is just a change to try to bring us in
line with chromium and the spec. As this has apparent web compat issues, and
DataTransfer is a hard to test area, this patch moves the changes behind a pref,
which we can come back to turning on after we ship 57.
When an <iframe> element has focus and its sub document isn't scrollable, the
parent document should be scrolled instead.
MozReview-Commit-ID: 5LSVDHDQGtI
--HG--
extra : rebase_source : 0b22a426ef0e4ab662c941f6bc759679c1b92b19
This is required for deCOMtamination. The patch removes the only script use of
this attribute, which is a low-importance one in a test.
--HG--
extra : rebase_source : 65c29043fbd77e60b21398216593cc9788723dd5
nsIIOService based events when used via SpecialPowers in mochitests
combined with the preloaded browser in the same process can cause
IsSafeToRun() assertion in SchedulerGroup.h:81. To avoid that we make sure that
previous tests in the suit do not create a preloaded browser. This cannot happen
in a real life scenario.
https://github.com/w3c/uievents/issues/112
This is supported by all other UAs. In the past we had compatibility
problems when trying to add support, but it seems these might be fixed
if we make all arguments optional beyond the first.
The interface chosen for the method is from the spec, which has been
updated to match Chrome. This is also very similar to WebKit, but the
final four arguments are different from IE.
MozReview-Commit-ID: 36AeX1JwJTt
--HG--
extra : rebase_source : 28b298d370f0f9a5ab4090a71a2aae91f1d90025
nsIIOService based events when used via SpecialPowers in mochitests
combined with the preloaded browser in the same process can cause
IsSafeToRun() assertion in SchedulerGroup.h:81. To avoid that we make sure that
previous tests in the suit do not create a preloaded browser. This cannot happen
in a real life scenario.
nsIIOService based events when used via SpecialPowers in mochitests
combined with the preloaded browser in the same process can cause
IsSafeToRun() assertion in SchedulerGroup.h:81. To avoid that we make sure that
previous tests in the suit do not create a preloaded browser. This cannot happen
in a real life scenario.
They were just dropped from the spec:
https://github.com/whatwg/dom/issues/362https://github.com/whatwg/dom/pull/489
ErrorEvent we never supported anyway until it was added recently to
match the spec. PopStateEvent is not supported by WebKit, Blink is
planning to try dropping support, our telemetry shows usage is
basically zero, and we never supported any way to initialize it anyway.
The changes to Document-createEvent.html and Document-createEvent.js are
taken from upstream. The other wpt changes are new in this commit.
MozReview-Commit-ID: A6GzhLwL08l
--HG--
extra : rebase_source : 4bdcd605b179ea787985845e9b1c53f76ebc179a