Previously, we waited for the load event and used that event timestamp.
But as far as I can tell the intent of this test is not to test the load
event specifically, but just event timestamps.
In opt builds, the reduceTimerPrecision pref was not being populated fast
enough to take effect during the load process, and was causing (a lot of)
intermittent failures.
We refactor the test to use PushPrefEnv and test a different event.
MozReview-Commit-ID: ILJYHRhUHnM
--HG--
extra : rebase_source : 659ebbe2442647d1166725637bcd716ad94b9980
Most of them just want GetRootFrame(), and there's no need to explicitly go
through the frame manager for that, we have a handy alias in the shell.
MozReview-Commit-ID: GriEqkasidY
This patch disables device sensors except orientation by default.
It implements per-sensor prefs to disable orientation, motion, proximity and ambient light
selectively. The patch also makes the pref checks happen at runtime (versus on process
start) using Preferences::AddBoolVarCache.
The patch also removes the related Event constructors also.
MozReview-Commit-ID: EA8ARjjtlkF
--HG--
rename : dom/events/test/test_bug742376.html => dom/events/test/test_deviceSensor.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_disabled_events.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_eventctors_sensors.html
extra : rebase_source : 39da98ac9226ac727f5197d28561b0b762da06f4
This is enough to get the stylo-enabled build green.
There's still some orange in WPT with stylo disabled (due to interfaces not
exposed and that) that I'll update tomorrow.
Will send a different patch on top of this for that, though I'll land together.
MozReview-Commit-ID: CsN5CM93RUz
As for now, the scrollable direction with a mouse wheel for a single-line text
control is hard-coded; that is, only horizontal wheel scrolls are able to take
effect while vertical ones aren't. However, this isn't the desired case for
vertical writing mode, where the opposite case definitely suits better.
This commit refines the hard-coded scrollable direction for a single-line text
control to be writing-mode-adaptive.
MozReview-Commit-ID: 4Zkoe2ExPCZ
--HG--
extra : rebase_source : 113b2ea80b6bbbcd2d8379b438de97eedd616551
Not calling SimpleTest.finish() causes the test to hang, which isn't helpful.
MozReview-Commit-ID: 2RBpjnG5B9l
--HG--
extra : rebase_source : b528b83f431c89ff5b21fdd725b2c371edd9b29a
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
Currently, we dispatch keypress event when Enter is pressed without modifiers
or only with Shift key. However, the other browsers dispatch keypress event
for Ctrl + Enter in any platforms even if it doesn't cause any text input.
So, we should fire keypress event for Ctrl + Enter even in strict keypress
dispatching mode.
Note that with other modifiers, it depends on browser and/or platform.
So, anyway, web developers shouldn't use keypress event to catch
Alt + Enter, Meta + Enter and two or more modifiers + Enter.
MozReview-Commit-ID: 3uUMkhL5VfJ
--HG--
extra : rebase_source : 8149acd958b238c8216f683a42fa05c3cf24570a
Now, callers of EventUtils.synthesizeKey() don't need to specify
KeyboardEvent.code value anymore if they assume that active keyboard layout
is US keyboard layout.
Note that this patch changes the meaning of only test_bug551434.html.
Some callers in it don't match the key value and code value but that looks
like that they don't checking such odd keyboard events. So, they must be
bug of the test.
MozReview-Commit-ID: Itxo7yZ9rkK
--HG--
extra : rebase_source : 856ef3715c924ca16e993ea57d92d1243b5cc6be
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
Boris Zbarsky
Olli Pettay
Tom Ritter
Bogdan Tara
Emilio Cobos Álvarez
Arthur Edelstein
Kartikaya Gupta
Chris H-C
Andreea Pavel
Jonathan Kingston
Florian Quèze
Tiberius Oros
Zhang Junzhi
Botond Ballo
Cosmin Sabou
Ben Kelly
Hiroyuki Ikezoe
Dorel Luca
Milan Sreckovic
Masayuki Nakano
Chris Peterson
Sebastian Hengst