This pref was used to enable the building of nsDisplayLayerEventRegions
items without APZ, so that we could test it in isolation. However, we no
longer need to do so, and these display items are going to be deleted
anyway, so we can remove this pref.
MozReview-Commit-ID: LJVcFafCKyS
--HG--
extra : rebase_source : 76d8eeca8dca4ea88b8226bbe6b829dbc40e03e4
Currently, TabChild discards eKeyDown and eKeyPress events which are marked as
"repeated" and were dispatched after the latest eKeyDown event comes into the
process. However, keyboard layout utils may generate native key events
as "repeated" even if each native key is important to input proper text.
So, TabChild shouldn't decide if coming keyboard event is skippable only with
mIsRepeat. For solving this issue, this patch adds
mMaybeSkippableInRemoteProcess to WidgetKeyboardEvent and makes
TabChild::SkipRepeatedKeyEvent() check
WidgetKeyboardEvent::CanSkipInRemoteProcess() instead.
On Windows, there are two ways to generate keyboard input messages. One is
using SendMessage() or PostMessage(). The other is SendInput() API. In both
ways, utils can make their input as repeated key messages.
The former case must be safe for this issue since such utils need to set 31st
bit of lParam to 1 explicitly.
On the other hand, in the latter case, the utils probably need to append
KEYEVENTF_KEYUP into KEYBDINPUT::dwFlags. Otherwise, only first call is
treated as non-repeated event.
So, when given message does not came from physical key operation, NativeKey
should set WidgetKeyboardEvent::mMaybeSkippableInRemoteProcess to false
even if WidgetKeyboardEvent::mIsRepeat is true.
MozReview-Commit-ID: 3rinrOjx8Tf
--HG--
extra : rebase_source : 26b6d869260176fc7ef535323b83001bb4b725c2
After fixing the document.domain exceptions to conform to the html
spec, NS_ERROR_DOM_BAD_DOCUMENT_DOMAIN is no longer used, and can be
removed.
MozReview-Commit-ID: 9CwrUSGy2K3
--HG--
extra : rebase_source : 6c624e407fd714f8c61e1e43d44089c0c1e64558
Change exception type to comply with HTML spec, which uses security
error instead of bad document domain.
MozReview-Commit-ID: Iefkeskn9bM
--HG--
extra : rebase_source : 282507d687c8fe19a326df95632694bcc6c5dd29
Make document.domain non-nullable, to conform to the HTML spec.
MozReview-Commit-ID: B1YuQekBgZD
--HG--
extra : rebase_source : 00999e16549e62c783f06f61c62000ab7677cf1d
Disable NetworkGeolocationProvider.js request cache for test cases that change the geo.wifi.uri. The cache does not remember from which location service the cached request came from and we expect different results when we change the provider URL (geo.wifi.uri).
MozReview-Commit-ID: 7SbhBOkek4H
--HG--
extra : rebase_source : 2ce410953eaa76e259472397163c304621449a61
extra : source : 058acdfc4d995120d0d2ed34c60b6151ce670d63
I hit this error when testing geolocation with Wi-Fi disabled. There is a race where the WifiGeoPositionProvider gets shut down (settting this.listener to null) but the xhr request is still alive (and the xhr callback later hits the null this.listener).
MozReview-Commit-ID: E3jCFM3om5A
--HG--
extra : rebase_source : 7a0409c2eca6629877aeb82b89fce55b5ff67f75
extra : source : 1e793af6b1731e59468d4222543c8dfaf951dc43
And change nsGeoPosition to store DOMTimeStamp instead of long long because it is a more descriptive type. DOMTimeStamp is a typedef for uint64_t, so we're not losing any precision using DOMTimeStamp instead of long long.
MozReview-Commit-ID: hjXnw959yC
--HG--
extra : rebase_source : 7061953cc62d116487ca2fa75d89f65cf725b573
extra : source : 014089341e5443fe0b42c98141c846bfa8ca6728
The Windows and macOS location providers used to start the MLS provider (with a two-second delay) and then call the operating system's location provider, letting them race. Currently, however, we only start the MLS fallback provider after the system provider returns an error, so the two-second startup delay is just wasted time.
I left the starup delay option in MLSFallback because the Linux gpsd provider still uses it to race MLS with the system's GPS provider.
MozReview-Commit-ID: 3ZFeF1g6PoG
--HG--
extra : rebase_source : ae7032fb86b9015686c160dd990dcb264fff742a
extra : source : 90473706de0fc0af9866b05768b7700de0fd552f
nsGeoPositionCoords will convert NaNs returned from the location providers to null properties of the JavaScript Coordinates object.
MozReview-Commit-ID: Cmuf2aO0ClD
--HG--
extra : rebase_source : cbccead609ff53a3e5f1bcf7698eba7382220ce5
extra : source : b4ced6e2bab2d17cf642f5850bda5998f635fccb
I've made the returned object from .bounds not live. If that's not OK, I'll
resurrect DOMBounds (removed in a previous patch). This also forces
DOMQuad.toJSON() to only return the points.
MozReview-Commit-ID: 10TY5oJUmTN
--HG--
extra : rebase_source : f965bd0593b512ec57ffc5268eecf3b4fe8e820a
Style overlays are no longer used outside of tests.
MozReview-Commit-ID: 798Id5JITAm
--HG--
extra : rebase_source : edfbfc973f865d72bbc019a26519436157476793
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
Cache AccessibleNode and make it able to operate the same instance by nsINode::GetAccessibleNode
--HG--
extra : rebase_source : 063eec8658af020f5408260d7d581ee76a04bd37
Andreea Pavel
Joel Maher
Bogdan Tara
Kartikaya Gupta
Masayuki Nakano
Kyle Machulis
Chris Peterson
Boris Zbarsky
Brindusan Cristian
Olli Pettay
arthur.iakab
Henrik Skupin
Ciure Andrei
Mats Palmgren
Xidorn Quan
Andreas Pehrson
Kris Maglione
Blake Kaplan
Brendan Dahl
Alex Gaynor
Cosmin Sabou
Jan de Mooij
Byron Campen [:bwc]
Christoph Kerschbaumer
Coroiu Cristina
Dan Glastonbury
Tokio Kajitsuka
Emilio Cobos Álvarez