As part of applet/java plugin removal in bug 1279218, classid checking
was removed, as it was not obvious that this was used anywhere other
than java plugins. The classid is still a valid attribute on object
tags (and is sometimes used on tags for flash embedding). We want
to use a fallback strategy when we find objects with classid
attributes, as we don't support them, meaning we need to revert our
prior removal of the check.
MozReview-Commit-ID: BKQ34HGTkvt
--HG--
extra : rebase_source : 671bc831a7b500ba1a5643a8dbae69dd0c44acf4
The changes made to this test make the test failure messages more useful. The
test is disabled because the test fails on some platforms. The failures seem
to indicate that, after a Find for text with multiple matches, the match that
is selected is not the first match after the currently highlighted text. Other
expected success indicators like total number of matches are correct.
Bug 1458393 has been opened to investigate this differing behavior and
re-enable the test.
MozReview-Commit-ID: 8Jwr9mKNzGr
--HG--
extra : rebase_source : a8a79a85e08dc5fdc7efe6b14f74a9bd18cb8864
Test changes for removal of PopupBoxObject and popup.xml methods, some reflow tests now have different stacks now that they are not going through popup.xml binding methods, test_popupanchor.xul changes due to need to wait for popuppositioned event after resizing. The old code would just adjust the arrow directly when sizeTo was called, but the new code does this through an asynchronous popuppositioned event. Changes to some places that check for XULElement class.
--HG--
rename : dom/webidl/PopupBoxObject.webidl => dom/webidl/XULPopupElement.webidl
rename : layout/xul/PopupBoxObject.cpp => dom/xul/XULPopupElement.cpp
rename : layout/xul/PopupBoxObject.h => dom/xul/XULPopupElement.h
We don't want to gesture activate for key and mouse/pointer events sent to
editable elements, as that would mean user interaction intended as text input
could start media playback, which would not likely be the user's intention.
MozReview-Commit-ID: VemPfpuziz
--HG--
extra : rebase_source : b2267f5ae2c9f0f6626f622bc98e3c5f18faf8bb
We don't want key presses of keys which are likely to be intended to be
interaction with the browser or OS to gesture activate documents and unblock
autoplay videos. So don't gesture activate for key events which are modifier
keys, or which don't have a pseudo char code.
MozReview-Commit-ID: 6uyPmlzbAvg
--HG--
extra : rebase_source : 8be949228b666a2ff54385f14b38b8f89459b1e2
extra : source : 59979388ba67d5fbfa8f3801bb65ac0fd2a49408
This patch changes ServoCSSPropList.py to use classes for properties.
This allows extending the data in the file without needing to update all
users of this file.
Sorting in GenerateCSSPropsGenerated.py is removed because the data file
has the right order already.
MozReview-Commit-ID: D74bItCfpPH
--HG--
extra : rebase_source : e0138c255f77515f491496fcb8680686362f4e9e
We don't want to gesture activate for key and mouse/pointer events sent to
editable elements, as that would mean user interaction intended as text input
could start media playback, which would not likely be the user's intention.
MozReview-Commit-ID: VemPfpuziz
--HG--
extra : rebase_source : b2267f5ae2c9f0f6626f622bc98e3c5f18faf8bb
We don't want key presses of keys which are likely to be intended to be
interaction with the browser or OS to gesture activate documents and unblock
autoplay videos. So don't gesture activate for key events which are modifier
keys, or which don't have a pseudo char code.
MozReview-Commit-ID: 6uyPmlzbAvg
--HG--
extra : rebase_source : 8be949228b666a2ff54385f14b38b8f89459b1e2
extra : source : 59979388ba67d5fbfa8f3801bb65ac0fd2a49408
Returning the same type and UpdateStyleSheet.
This hopefully helps seeing how the data flows between the methods, instead of
the messy bits we had before.
MozReview-Commit-ID: C6THNRi8bbg
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
DecoderDoctorLifeLogger now passes a NonDereferenceable pointer to
LogConstruction/LogDestruction, to avoid UBSan errors. It is possible because
DDLogger only keeps pointer values for logging (the pointer type is converted
to a string), these pointers are never actually dereferenced.
Note that the uintptr_t value() is converted to `const void*` because that's
what DDLogger uses everywhere; an upcoming bug will make DDLogger use
NonDereferenceable everywhere instead.
MozReview-Commit-ID: K5wJrGVCub0
--HG--
extra : rebase_source : cc802706d1c2c5a60ac692d132038c8418f8dedd
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
In bug 1237454, we introduced a new change hint that is produced when
visibility property is changed from 'visible' to 'hidden' or from 'hidden'
to 'visible'. Animations producing this new change hint can be throttled
if the animation element is out-of-view, but can not be throttled in the case
where the element is in-view. In the bug, a test case for a visibility change
animation on out-of-view element was added, but no test for in-view case was
added.
MozReview-Commit-ID: BhiRm13rfRr
--HG--
extra : rebase_source : 264954ff349d5a9c5a00b940b2eaf2045f0952ae
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
Boris Zbarsky
Olli Pettay
shindli
Ben Kelly
Karl Tomlinson
Emilio Cobos Álvarez
Kyle Machulis
Jean-Yves Avenard
Alex Gaynor
Alex Chronopoulos
Brad Werth
Csoregi Natalia
Kartikaya Gupta
Cosmin Sabou
Paul Adenot
Mark Banner
Eric Rahm
Eugen Sawin
Bobby Holley
Neil Deakin
Chris Pearce
Xidorn Quan
cubouyaka
Jon Coppeard
Andreea Pavel
Andrea Marchesini
Jeff Walden
Kris Maglione
arthur.iakab
Tiberius Oros
Gurzau Raul
Robert Longson
Brian Birtles
Dorel Luca
Nils Ohlmeier [:drno]
Brindusan Cristian
Alexandre Poirot
Brian Grinstead
Hiroyuki Ikezoe
Tarek Ziadé
David Major
Tom Ritter
Christoph Kerschbaumer
Dragana Damjanovic
Noemi Erli
Ciure Andrei
Nathan Froyd
Andrew Sutherland
Andrew McCreight
Gerald Squelart
Timothy Guan-tin Chien
Jean-Luc Bonnafoux
Narcis Beleuzu
Jonathan Kingston
Gijs Kruitbosch
Margareta Eliza Balazs
Valentin Gosu
Jonathan Kew
Jan Varga
vinoth
Tyson Smith
Cristina Coroiu
Adrian Wielgosik
Steve Fink
David Parks
Bryce Van Dyk
Dão Gottwald
Kershaw Chang ext:(%2C%20Valentin%20Gosu%20%3Cvalentin.gosu%40gmail.com%3E)
Stephen A Pohl
Jeff Gilbert