The change from "docShell" to "mDocShell" for the SetName call in the
OwnerIsMozBrowserFrame case in nsFrameLoader::MaybeCreateDocShell is a
drive-by correctness fix for a bug the rename of "docShell" to "parentDocShell"
caught: setting the name of our _parent_ docshell based on the name attr of our
owner makes no sense.
MozReview-Commit-ID: DwnWt8jTokV
Unlike a DOM wheel event listeners which receive original delta values, plugins
receive horizontalized ones. It's not reasonable to not send original values to
plugins.
Plugin developers can do any delta adjustment, and they are also capable of
DIRECTLY getting what inputs the user is manipulating, that is to say,
developers can horizontalize scrolling for [Shift+Vertical Wheel] or other other
inputs if they want, it's just their matter; conversely, they aren't capable of
getting what delta adjustment their upstream has already encapsulated for them.
So it's not reasonable to send adjusted delta values to plugins.
This patch restores horizontalized delta values to the original for plugins.
MozReview-Commit-ID: IX8XJn0lbKq
--HG--
extra : rebase_source : ea9abef4706701e2c43ee06563bd10bc0a863614
We attach it to WorkerPrivate and DOMNavigationTiming so it will be re-used
when it should.
WorkerPrivate is used in the Performance APIs, Performance Storage Worker,
and Event.
DOMNavigationTiming is used only in the Performance APIs, but the crucial
part is that when the individual DOMNavigationTiming object is re-used,
so will the context seed. This in particular came up with the
nav2_test_document_open.html Web Platform Test which illustrated the fact
that even if you .open() a new document, the performance navigation data
is not supposed to change.
MozReview-Commit-ID: GIv6biEo2jY
--HG--
extra : rebase_source : da2ad8d9d6e0172679c6af14dba72938e9d2012c
The compartment-per-addon code was added so that we could segregate at least
some of the code from system-privileged add-ons into tagged compartments, even
when it ran in browser windows. That allowed us to apply certain special
behavior to them, such as enabling e10s shims, and to track some performance
characteristics.
The only remaining chrome-privileged add-ons now are system add-ons controlled
by us, and the shim system and per-compartment performance metrics are gone,
it no longer serves a purpose.
MozReview-Commit-ID: Ap186bWAaqP
--HG--
extra : rebase_source : c5bf81b44dd42b7cebce2784b7dd98480b41b593
There can be something shuffling the iframe between the mouse event is sent and
the mouse event is received which makes us end up targeting the <body> instead
of the test target.
This can be reproduced with enough persistence either with and without the
patches from bug 1439875, at least on a headless build with rr chaos mode.
Move it to test_group_pointerevents in the apz tests to run it in a new window
and make it a bit more reliable.
MozReview-Commit-ID: BS6Es8iEmMY
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
When native key event is handled by IME, we should set keyCode to 0xE5 (229,
VK_PROCESS of virtual keycode of Windows) for behaving same as the other
browsers.
This patch declares it same as other keyCode values.
MozReview-Commit-ID: 666bB1qOEgv
--HG--
extra : rebase_source : 063df635c13a416a6d89050ac45c7803a163ede0
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
This affects several tests, and in all but one case merely disables timer precision
reduction on those tests.
In the other singular test, it no longer requires 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 : c82310ce0269798a9c5bfffaec1f63a24ddc98e5
In current draft, selectionchange event should be fired when Selection is
changed in Document. However, selection of <input> and <textarea> is different
from Selection in web standards (although our implementation uses Selection).
So, we should check it with SimpleText.executeSoon() for now since it might
be possible that selectionchange event in <input> and <textarea> would be
removed completely.
MozReview-Commit-ID: APvMwbysDzs
--HG--
extra : rebase_source : 3d9cf8c8e8c997744909c087862707f741d170d6
Also, remove a now-obsolete comment from placesOverlay.xul and remove
some now-empty XPCShell test head files.
MozReview-Commit-ID: 6kKVQu8FAL3
--HG--
extra : rebase_source : 7dd05818d68a15bd170af734078db4ba45029d80
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <