Aside from making things easier for JS callers, this also makes it harder to
accidentally trigger an early load of the service, which can be expensive
during startup.
This also makes a slight change to nsPluginHost to initially preserve the
previous blocklist state when a plugin is updated, to avoid the risk of the
possible additioanl asynchrony unblocking a plugin that should stay blocked.
MozReview-Commit-ID: 4EvIGJ1Ke0Z
--HG--
rename : toolkit/mozapps/extensions/nsBlocklistService.js => toolkit/mozapps/extensions/Blocklist.jsm
extra : rebase_source : e7047615ea3a728478695c76a0c521b0281f363b
extra : amend_source : b74115abacacd17ae3e8433a534a5bbb541905b0
The test added in this patch fails without the corresponding code changes
(specifically the second gGetComputedTimingTests test fails the comparison of
the 'easing' member).
MozReview-Commit-ID: 9eyXruVrPuN
--HG--
extra : rebase_source : 927f55c0670bf770e03d38eb876202efbb700c1e
It seems to me that only the remaining three types are actually used by
the devtools, so I remove other types to reduce the scope.
MozReview-Commit-ID: 5mm3nl9qOyQ
--HG--
extra : rebase_source : 3af817ced34fdd08df8d18e25d3834eb19a21652
extra : source : 452a68930d96300a0ac35f1a261f72a2fa04e513
On WebRender, the animation on the visibility hidden element runs on the
compositor somehow.
MozReview-Commit-ID: 77dVlIeFQ3u
--HG--
extra : rebase_source : 2b93833e9bf5ed17f3e4ee5306bdcfd57e3c87a4
PerformanceCounters are currently disabled in two ways:
- a preference that's off by default "dom.performance.enable_scheduler_timing"
- calls made only for nightly using #ifndef RELEASE_OR_BETA
In order to simplify the code, let's remove the #ifndef and rely only on the pref.
That will also allows us to use the feature in every version going forward.
The performance will not be impacted since the current code is already using
the (cached) pref value to determine if the counters are used.
MozReview-Commit-ID: 47t2M1O13aH
--HG--
extra : rebase_source : e129e1829f1dc37c019e50e156474c4876d6d6cb
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
The rules set in place in bug 839886 and bug 1377826 prevents any native
anonymous content to participate in auto-direction, both on having dir=auto
to work on it and have it to affect the direction of non-anonymous dir=auto
parent.
This patch relax the rules a little bit by allowing the anonymous element with
dir=auto to particiate in auto-direction. For simplicity, it would allow the
text node in to affact auto-direction only if the text node is the direct
children of the dir=auto parent.
This patch is needed for HTML-based in-content widget to display RTL
labels correctly. It shouldn't change any UI on its own; the purpose of
the fix here is to display RTL-text filenames correctly when bug 1446830
is fixed.
The change is needed in ResetDirectionSetByTextNode() because
when CC clean-up the document, the function is called from
nsTextNode::UnbindFromTree(). At that point, IsInAnonymousSubtree()
will cause an assertion error on when calling SubtreeRoot(),
since subtree hierarchy is already broken by earlier UnbindFormTree()
calls to our parent nodes.
Substitute that check with HasTextNodeDirectionalityMap() in and only
in ResetDirectionSetByTextNode() should be ok -- given the function
doesn't really do anything if HasTextNodeDirectionalityMap() is false.
There is no need to call EnsureMapIsClearFor() when the condition is false
either; EnsureMapIsClearFor() itself is a no-op if the condition is false.
MozReview-Commit-ID: GqF5ypDZcbH
--HG--
extra : rebase_source : e6bfd3d5792be73a8bbb768c7d5b122170b2f02a
extra : source : 6aeb0958693ccc51346713faad823debd9cceeae
This will allow us to make nsIPluginTag a builtin class.
This patch also factors out some common logic from AOM plugin tests.
MozReview-Commit-ID: FbXlSE8sjyK
--HG--
extra : rebase_source : 6403a62bcd6d5a1481c0b4d74c41339f659280ca
After discussing with Olli there isn't any kind of severe problem out of this.
Shadow subtrees will be disconnected just like the rest, and they shouldn't
assume that the document hasn't been disconnected first.
MozReview-Commit-ID: CX4fXOqEIFj
--HG--
extra : rebase_source : cd30cb8b8199fb73120c0bcade68986454090005
This is used in JS via instanceof checks, and in C++ only to get the `inputField`
attribute (the actual HTML input or textarea). We can swap out instanceof by checking
the tag name, and we can directly query for the input field from C++.
MozReview-Commit-ID: 7xpHQMYzYhD
--HG--
extra : rebase_source : a5b62928665725133eb52e4df2fb6659a6109ffd
Nothing from within CompatibilityModeChanged can kill it.
MozReview-Commit-ID: 386GiYBC6kF
--HG--
extra : rebase_source : ac93fb98dce07b04381cd5429cb1bc693c1fd07a
In this case the stylist is marked dirty because a compat mode change. The
change just doesn't exist (NavQuirks -> NavQuirks).
So avoid the work in the first place.
MozReview-Commit-ID: lchKJECNkO
--HG--
extra : rebase_source : 421bd4147da5dfa83f8f82d05228175c70cf5615
Given that resizer.svg will be loaded in non-chrome documents, we will
need to exclude it from the use counter.
MozReview-Commit-ID: 4ZzidKJUfBW
--HG--
extra : rebase_source : 9ce9d6e6a312695cfd19243499051bf26d91f79b
* Also keeps the timing array as nsTArray<nsCOMPtr<nsIServerTiming>> instead of the scriptable nsIArray (which doesn't like being released on another thread)
MozReview-Commit-ID: 37uPZJ38saQ
--HG--
extra : rebase_source : 099ec74c3032ef6033d187a028466777200c6015
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
Instead of contending with the idiosyncracies of the platform implementations of condition variables, which have been leading to strange crashes, we hold this mutex as a ref-counted object and avoid complex object lifetime reasoning.
Currently, the document entry is created at the first time when some JS code tries to access it. But for the case when server timing headers exist for a document loading channel, we need to create the document entry and save the server timing data in the document entry.
If we don’t do this, the server timing data would be lost since the http channel will be deleted.
MozReview-Commit-ID: B5ksAZvZACq
--HG--
extra : rebase_source : 27bc6284ec417b2ff430a59cd9eeddc56b7a77ac
Test steps:
1. Create a XHR to get serverTiming.sjs.
2. Add Server-Timing headers in serverTiming.sjs.
3. Check if the value from PerformanceResourceTiming is correct.
MozReview-Commit-ID: KOQhoFQv4fy
--HG--
extra : rebase_source : a0f5bde872ca9e066764d90ab80d7848988f37a8
This patch:
1. Introduces PerformanceServerTiming.webidl.
2. Adds serverTiming in PerformanceResourceTiming.webidl.
3. Gets serverTiming data from nsITimedChannel and keeps it in the PerformanceTimng class.
MozReview-Commit-ID: 9mkGkHbxopC
--HG--
extra : rebase_source : 7e0d0321e71eb0af9591ead76dc163996fbaf819
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
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
Some DOM unit tests rely on being able to parse XUL via DOMParser. That was allowed due to them calling init() with a system subject principal. It can be more narrowly allowed by adding an explicit setter for being able to parse XUL/XBL.
MozReview-Commit-ID: 3h0WWGHmYOn
These are not needed, and they were removed by bug 1452981, but then that was
backed out. They obviously don't compile as written with nsIDOMEvent removed,
leading to a CLOSED TREE
MozReview-Commit-ID: FH5QqKEgalP
Kris Maglione
arthur.iakab
Tiberius Oros
Gurzau Raul
Robert Longson
Brian Birtles
Xidorn Quan
Dorel Luca
Emilio Cobos Álvarez
Nils Ohlmeier [:drno]
Brindusan Cristian
Alexandre Poirot
Brian Grinstead
Hiroyuki Ikezoe
Tarek Ziadé
Boris Zbarsky
Tom Ritter
Christoph Kerschbaumer
Dragana Damjanovic
Noemi Erli
Andrea Marchesini
Ben Kelly
Ciure Andrei
Nathan Froyd
Andrew Sutherland
Andrew McCreight
Timothy Guan-tin Chien
David Major
Jean-Luc Bonnafoux
shindli
Kartikaya Gupta
Narcis Beleuzu
Jonathan Kingston
Gijs Kruitbosch
Margareta Eliza Balazs
Valentin Gosu
Jonathan Kew
Jan Varga
vinoth
Eric Rahm
Adrian Wielgosik
Paul Adenot
Steve Fink
David Parks
Bryce Van Dyk
Dão Gottwald
Kershaw Chang ext:(%2C%20Valentin%20Gosu%20%3Cvalentin.gosu%40gmail.com%3E)
Chris Pearce
Karl Tomlinson
Olli Pettay
Cosmin Sabou
Stephen A Pohl
Andreea Pavel
Jeff Gilbert