This commit only introduces the concept and the functionality of retrieving the
values from the two new related prefs. Still no actual functionality change is
involved.
MozReview-Commit-ID: 2Gl3Wqdo6jL
--HG--
extra : rebase_source : bf30483e3e32829a5d6fd927740471ba348448f9
Do some work in preparation for implementing actual functionalities for this
bug. No actual functionality change is involved in this commit.
MozReview-Commit-ID: 5aLhr38n1N4
--HG--
extra : rebase_source : 15cfc2cea5b7668367dd3bd4a0746ae8c61b7d20
The test change is needed because there is no notok() function. But the old
nsIDOMEventListener setup would fail to report the exception anywhere, so the
test still passed (albeit without testing what it thought it was testing). The
new setup reports the exception via an error event on the window, and the test
harness notices that.
MozReview-Commit-ID: 3ISmcyhMk0R
We could have used the new NS_NewCStringInputStream overload here, but
it seemed nicer to directly transfer ownership into the newly-created
stream. If we're going to be more efficient here, we might as well go
as far as when can without making the code too ugly.
The security checks outer window did here don't seem right, because the whole
point is that this method is only called by C++ code for its own purposes.
We're not adding random untrusted listeners via addSystemEventListener!
MozReview-Commit-ID: JdS5gTESclu
The CanCallerAccess check in the "webidl" version of
nsGlobalWindowOuter::AddEventListener was pointless, because bindings never
call things on outer windows.
MozReview-Commit-ID: 1CGMJ277bPu
Also switch the XPCOM-y version of EventTarget::AddEventListner to a
Nullable<bool> for aWantsUntrusted.
The three-arg overload of AddEventListener in ContentFrameMessageManager was
never called, so all the AddEventListener overloads there are not needed.
MozReview-Commit-ID: 4IhqHmPVWzE
We can't have a null content in
ScrollbarActivity::StopListeningForScrollAreaEvents, because only viewport
frames have a null GetContent().
MozReview-Commit-ID: 9iAg0ivVqqG
And then fix up everything else that needs to change as well.
MozReview-Commit-ID: GDMfERqdQAc
--HG--
extra : rebase_source : 01fe06c3182245a409099a53383d92bf4fa0155c
On Mac, when dragging an image, add the image request's MIME type to
the transfer so that the MIME-extension check can be done in the
parent process to avoid content sandboxing issues.
MozReview-Commit-ID: 3cb4fCr6GnL
--HG--
extra : rebase_source : 43720237b467765401b5504c57bbc1b43d4dfdc0
Calling GenerateDragGesture at this point should not be necessary, since
eTouchMove events are already handled in the same function. This code
is intermittently triggered through (what I can only call "rogue")
eMouseMove, ePointerDown and ePointerMove events, which is causing hangs
in the native DoDragDrop function further down the stack.
Arguably this shouldn't be triggered by e.g. ePointerDown either, and
I'm unclear on why exactly DoDragDrop is hanging (likely because it is
called again before the user does a drop), but this is a quick fix that
should be suitable for uplift.
MozReview-Commit-ID: A0hBlS85icx
--HG--
extra : rebase_source : 4d26c92c556068fc25dca5ad5d106187274b3e2a
When dragging an image, add the image request's MIME type to the transfer
so that the MIME-extension check can be done in the parent process.
Move the MIME-extension check to the parent process to avoid
issues caused by content process sandboxing.
MozReview-Commit-ID: 3cb4fCr6GnL
--HG--
extra : rebase_source : ec49b8c83613be844fe4cd88a5024ac41a845199
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
Zhang Junzhi
Boris Zbarsky
Tristan Bourvon
Nathan Froyd
Ciure Andrei
Olli Pettay
Andreea Pavel
Nicholas Nethercote
Ben Kelly
Haik Aftandilian
Johann Hofmann
Thomas Wisniewski
Jason Orendorff
Coroiu Cristina
Gurzau Raul
Margareta Eliza Balazs
Noemi Erli
Nils Ohlmeier [:drno]
Emilio Cobos Álvarez
Tom Ritter
Hector Zhao
shindli
Kris Maglione
arthur.iakab
Bogdan Tara
Arthur Edelstein
Kartikaya Gupta
Chris H-C
Jonathan Kingston
Florian Quèze
Tiberius Oros
Botond Ballo
Cosmin Sabou
Masayuki Nakano
Hiroyuki Ikezoe
Dorel Luca
Milan Sreckovic
Chris Peterson
Sebastian Hengst