requestPerformanceMetrics should not be made available in the Worker scope.
MozReview-Commit-ID: K2nY6JIzWrE
--HG--
extra : rebase_source : 8f2bb788d20c419072c49a5ec910001bc9cd9508
We should gesture activate documents in key/mouse down instead of up because
if a web app wants to play a video inside a key/mouse handler, the document
needs to be activated before the handler runs.
Also, Chrome activates on key/mouse down, so we may have compat issues if
we have different behaviour.
MozReview-Commit-ID: JgGaQcNQfzz
--HG--
extra : rebase_source : edf5673be59a3714c3dd4eb239efd17d6a91ec32
We should gesture activate documents in key/mouse down instead of up because
if a web app wants to play a video inside a key/mouse handler, the document
needs to be activated before the handler runs.
Also, Chrome activates on key/mouse down, so we may have compat issues if
we have different behaviour.
MozReview-Commit-ID: JgGaQcNQfzz
--HG--
extra : rebase_source : de4269db9538e9c8aa5ff686c215bd619cf0c573
The WorkerJSContext is created and destroyed after entry and before exit from
WorkerThreadPrimaryRunnable::Run(). WorkerPrivate::EnterDebuggerEventLoop()
is called only while WorkerThreadPrimaryRunnable::Run is on the stack, and so
the CycleCollectedJSContext will not change.
MozReview-Commit-ID: HMJ8fpKC6E3
--HG--
extra : rebase_source : d481f4513f9e5ed29224ce01534fa3de95bc7ae4
The caller of WorkerPrivate::DoRunLoop() keeps the WorkerJSContext alive, and
so there will always be a CycleCollectedJSContext in DoRunLoop.
WorkerPrivate::EnterDebuggerEventLoop() assumes that
WorkerPrivate::GetJSContext() returns a JSContext, and so
EnterDebuggerEventLoop also must only be called while DoRunLoop is on the
stack and therefore keeping the WorkerJSContext alive.
MozReview-Commit-ID: EJgt73LsTx1
--HG--
extra : rebase_source : 257456bf7df5e84dfdf74cd136fd79d1698000d3
Note that we have to calculate animation values if there is another animation
since the other animation might be 'accumulate' or 'add', or might have a
missing keyframe (i.e. the calculated animation values will be used in the
missing keyframe).
MozReview-Commit-ID: rQyS9nuVJi
--HG--
extra : rebase_source : 6ddc70308e223a709eba9c4c2f05e42bbc0f3160
ProtocolName() is only used for producing error messages and annotating
crash reports. But examining actual crash reports that would have used
the result of ProtocolName() indicates that we can always tell what the
erroring protocol is due to the stack backtrace. So having this virtual
function around just provides duplicate information, and it takes up too
much space in the vtable besides. Let's get rid of it.
Not doing this can cause a leak because there is a cycle between the
load request and the script element.
MozReview-Commit-ID: E7GbH5iDBP6
--HG--
extra : rebase_source : b9c16b5a40bf465f28f792cbf727909d1f976c31
We already reject the play promises when we call Pause(), so this extra
reject is unnecessary.
MozReview-Commit-ID: 6LKw7hCwJPH
--HG--
extra : rebase_source : b75c147c2f475cf1ae4b4dddc3085c306f31d6e6
Bug 1435133 introduced a new path where we block autoplay and reject the play()
promise, but we didn't fire a "pause" event. This confuses YouTube's controls.
Additionally, even if we're not in a user generated event handler, we
unilaterally consider the media element blessed if execution reaches here:
https://searchfox.org/mozilla-central/rev/11a2ae294f50049e12515b5821f5a396d951aacb/dom/html/HTMLMediaElement.cpp#4110
We previously rejected before reaching here when not in a user generated event
handler, but now if play() is called before we've reached loadedmetadata, we
reject the promise if we're not in a non-event handler and bail out early, and
so we'll bless even if not in a user generated event handler. Meaning when we
do reach loadedmetadata, we think we were in a user generated event handler
when play() was originally called, and so we won't reject the play promise.
So this patch ensures we dispatch a "pause" event when we reject the play()
promise here. The WHATWG spec says we should do this when pausing anyway.
Note: calling our interal Pause() function when rejecting the play() promise
here breaks YouTube, as if we do that we fire a "timeupdate" event. So I opted
to manually code to fire the event here instead of just calling Pause()
everywhere we want to ensure we're paused.
MozReview-Commit-ID: 1snkiTnPGih
--HG--
extra : rebase_source : 2c5ca6c0ed7c2dff2fb971cd159cfdc12a8a227f
For the async caller, pretty much everything can be extracted out of the loader
/ loadData.
For the sync callers, we need to be a bit more careful because ReparseSheet
tries to get its line number on its own.
I changed the compat mode passed to the reparse stuff to be the document's one
in this case, but that seems a bug fix.
MozReview-Commit-ID: 2wi5HPRAlPi
Thunderbird uses DOMParser from C++ for now. They should ideally migrate that into JS, but we can give them something that works for the moment.
MozReview-Commit-ID: C4D6QuFdbn8
We always have one now. So we can remove all the codepaths that attempted to
handle the !mPrincipal case.
We can also remove the nsContentUtils::IsSystemPrincipal(mPrincipal) codepaths,
because that can never happen: DOMParser::Constructor never creates a DOMParser
with a system principal.
MozReview-Commit-ID: EUrGoiI0o3u
In our test suite, we only run into two calls to this constructor with a system
principal, and both are in test code.
After this, calling the WebIDL constructor from system code is _almost_
equivalent to creating by contract. The one difference is that the resulting
DOMParser (and the documents it creates) will have its script handling object
set to the global the constructor came from instead of being null.
MozReview-Commit-ID: Fe2yMeqoYnB
Emilio Cobos Álvarez
Tarek Ziadé
Chris Pearce
shindli
Karl Tomlinson
Hiroyuki Ikezoe
Ciure Andrei
Nathan Froyd
Andrew Sutherland
Ben Kelly
Brian Grinstead
Andrew McCreight
Tiberius Oros
Olli Pettay
Cosmin Sabou
Andrea Marchesini
Stephen A Pohl
Noemi Erli
Kartikaya Gupta
Andreea Pavel
Boris Zbarsky