1. Adding new checks in ConstructorChromeScript.js to checking the top level
document's principal information.
2. Adding a new test testCrossOriginTopLevelPrincipal in
test_constructor.html to testing the topLevelPrincipal attribute under
cross origin situation.
3. Removing some useless mochitest browser-chrome testcase.
Getting the top level document's principal when constructing PaymentRequest,
then sending it to chrome process and saving it in nsIPaymentRequest.
Creating a new readonly attribute nsIPrincipal topLevelPrincipal in
nsIPaymentRequest for UI to query the top level document's principal
information.
A lot of this involves copy-pasting the existing Servo style structs code.
Note that nsArenaSizes had to be moved after nsStyleSizes, because the former
now contains an instance of the latter.
MozReview-Commit-ID: 3hrkobxbX9b
--HG--
extra : rebase_source : f6b29bd7cb9bd60f2da65f5f907e161299333287
Another plumbing-only change, which is a precursor for the next patch.
ComputedValues are a Servo-only thing, so in order to use nsStyleSizes for both
Gecko and Servo, the ComputedValues sizes must be moved out.
MozReview-Commit-ID: BOnQSzzV0vC
--HG--
extra : rebase_source : 025c6161e509401a36525349083dd98bfda35621
This is a purely non-functional plumbing change. Instead of passing a
SizeOfState and an nsStyleSizes a bunch of places, we pass an nsWindowSizes,
which contains both of them.
This is a necessary precursor for the next patch.
MozReview-Commit-ID: Ek03wDM50rB
--HG--
extra : rebase_source : 7b05708bd21dc4e3812ea041647fa74bb413d0b9
Memory reporting was recently added for these DOM performance objects, but we
failed to report the "window-objects/" totals for the entire process. This
patch adds that.
MozReview-Commit-ID: 41ZcPC3seFc
--HG--
extra : rebase_source : fb4ed30ba3312e2c3fb5e1f9b186726c5ec2cd0f
This patch just moves code around, so that the reporting is done in the same
order that the nsWindowSizes fields are declared. This makes it easier to see
whether anything has been missed.
(I'd like to use macros to generate this repetitive code instead of writing it
by hand, but that's a task for later.)
MozReview-Commit-ID: Eu9Y078VNp
--HG--
extra : rebase_source : 95f31034a39c1057115ec4ea825ea33a774d5388
As part of the normalization process for WebExtension API calls, we need to
extract and validate the full set of value properties (including properties
X-rays would normally deny access to) from cross-compartment objects. This
currently involves waiving X-rays, enumerating property descriptors, and
unwaiving X-rays - all through X-ray wrappers and waivers - and generating a
lot of expensive and short-lived wrappers in-between.
This helper reads out the list of safe properties from within the object's
compartment, and then copies them over to an object in the target compartment,
without any X-ray overhead, or any unnecessary intermediate wrappers or
compartment switches. It cuts about 40% off the overhead of our normalization
code.
MozReview-Commit-ID: H582oAYocaX
--HG--
extra : rebase_source : 7f7d5df605bc6544cb7f1c0c7e224d81b211e09c
extra : histedit_source : f980a03413b5e65fc6fa272c012a769d2764d89b
In the code that I'm profiling, the XPC WrappedNative overhead of calling
these functions adds up to about a quarter of the time spent executing the
code. The overhead of the WebIDL versions is negligible.
MozReview-Commit-ID: 30qJy5RtP9d
--HG--
extra : rebase_source : 4fe73f4b9bde052a0eadf7d5634f792e16ca1c94
extra : histedit_source : ec61152a0181f3b0e28023c951e7181c43216d2f
There is no reason that SetTextRangeStyle is defined at nsISelectionPrivate. Also, SetTextRangeStyle isn't scriptable, and is called from CompositionTransaction::SetIMESelection only. So we should move this to Selection.
MozReview-Commit-ID: FCOA6wVhvYZ
--HG--
extra : rebase_source : 64eb9e5fb973195b2c87ab4eb296685c8a4d0319
* test_playback_rate.html
In the patch2, we would honestly return the value of playback rate.
* test_info_leak.html/test_load.html
According to [1], we should only dispatch event "ratechange" when playbackRate or
defaultPlaybackRate attribute has just been updated. In these tests, they didn't
change the playbackRate or defaultPlaybackRate, we should not expect for the
"ratechange" event.
[1] https://html.spec.whatwg.org/multipage/media.html#event-media-ratechange
MozReview-Commit-ID: LjVDNnf4YX4
--HG--
extra : rebase_source : 3b58649212c24ccd5e17a64c3dc7fce8a9600207
According to [1], we should return NotSupportedError for the negative playback rate.
[1] https://github.com/w3c/web-platform-tests/pull/6522
MozReview-Commit-ID: KoqDkBmP3h9
--HG--
extra : rebase_source : ddf1cdd03a980686df6d6613e1bd507bf37d8337
Test drawArray() after calling deleteBuffer() for the binded buffer.
MozReview-Commit-ID: 306tsklZK4L
--HG--
extra : rebase_source : 9ae4b33accc57406695ad6ee8f3d71fdf4d58442
If the buffer status was changed, we should do the ValidateBufferFetching() again.
MozReview-Commit-ID: 7czQFT3qauE
--HG--
extra : rebase_source : ee2635289d0d3e7c115b2a9d9f52c3ae876830d5
We allow swapping frameloaders between unrelated documents, so we need to
reparent wrappers when the owner content changes.
MozReview-Commit-ID: LNIf4ZrCZLo
--HG--
extra : rebase_source : 8041d1601962d61e675e78e3447c7772eee89df0
XPConnect wrapper overhead for this interface has been showing up heavily in a
lot of my profiles, in some places accounting for 50ms of the 80ms we spend
getting getting <browser> messageManagers. This improves the situation
considerably.
MozReview-Commit-ID: 9d1hCORxsYG
--HG--
rename : dom/base/nsIFrameLoader.idl => dom/webidl/FrameLoader.webidl
extra : rebase_source : d8a1fc1a19632ba36a9fc6f63873f7534671a13b
Jan de Mooij
Makoto Kato
Andrea Marchesini
Eden Chuang
Chris Pearce
Sebastian Hengst
Ryan VanderMeulen
Wes Kocher
Bevis Tseng
Matt Woodrow
Nicholas Nethercote
Andrew Halberstadt
Kris Maglione
Honza Bambas
JW Wang
Dão Gottwald
Alastor Wu
Marco Bonardo
Chung-Sheng Fu
Andreas Farre
JerryShih