We will need to modify these members off the main thead while IsAvailableForSharing()
is a main thread only function.
InitAsClone() will return an error if the original stream ends abnormally.
MozReview-Commit-ID: 1qRyboca2YZ
--HG--
extra : rebase_source : 4617a911a1de052833bd0085b883a8ae4d639c7d
This was needed before as the base to nsGlobalWindow, but now that
nsGlobalWindow doesn't exist, and we only have specific versions, we no longer
need this type.
MozReview-Commit-ID: 6IJmJtnSkMr
--HG--
extra : rebase_source : d21068aa7da89a6d49ead2477b91577809f5856a
There are many helper methods and structs in nsGlobalWindow.cpp. Many of these
are used by only the inner or only the outer window, while some are used by
both. In the case of the items used by both, I extracted them into
nsGlobalWindow.cpp, which includes nsGlobalWindowInner.cpp and
nsGlobalWindowOuter.cpp as the compilation unit entry point.
In the case of items used by just one or the other, I removed them from the
other file, and deleted the bodies of functions which used them, replacing them,
with a MOZ_CRASH.
This gets gecko building again, so that we can make further incremental
improvements.
MozReview-Commit-ID: 8QnJ1PX6TAO
--HG--
extra : rebase_source : 0eac00ad757f825a22a1af95d0a01d6fa92d824d
After the window split is complete, the inner window linked list won't be
homogenously typed anymore, as there will be an nsGlobalWindowOuter member in
addition to the nsGlobalWindowInner members. This patch changes the code to
perform PRCList* pointer comparisons before casting to nsGlobalWindowInner to
avoid this issue.
MozReview-Commit-ID: 56q5XodtGe7
The method doesn't use any MSG member, only dispatching a task.
MozReview-Commit-ID: 7uZbTvq9OQt
--HG--
extra : rebase_source : e12c5ffcb6479ab2bc06973121c291e759db23a4
mStreams should only ever be accessed on the MSG thread. However, under some shutdown circumstances, it can be accessed on the main thread while the MSG thread is still alive.
This will be corrected in bug 1408276.
MozReview-Commit-ID: 6xWzxxV1Dv3
--HG--
extra : rebase_source : bce92961609da6ea8609ec8ada5a8a30263a84c9
mForceShutdownTicket and mShutdownTimer are only ever accessed on the main thread. We don't need the use of the monitor to reset them.
MozReview-Commit-ID: 1DL8bLmzEH5
--HG--
extra : rebase_source : 84d56c7f4428143426cd22e88ef2912330efba4e
We only access mLifecycleState via a helper which strongly enforced how the member can be accessed.
Two non-safe accesses are corrected.
MozReview-Commit-ID: 6LYk7t4rSyB
--HG--
extra : rebase_source : 9727771e1b04ba1b39f5cf9a6cf94093b7e92b27
They are accessed across multiple threads without the use of monitors.
While it could be argued that some use of the monitor in functions accessing those members would set in place memory barriers, making them atomics remove all doubts as to the thread safetyness of their use.
MozReview-Commit-ID: tyTqeGgDNM
--HG--
extra : rebase_source : 420c38abcfeaa5fca2449034d8e1e3d82949d49d
Describe which members are accessed on the main threads. Other members are only accessed on MSG thread.
MozReview-Commit-ID: CFU4ipRHB1P
--HG--
extra : rebase_source : ad4843da513997a633d2d402384f9478df29c3a7
The WaitForDataPromise cannot be resolved even when key has been updated and decode request has be resolved.
2 ScheduleUpdate(NotifyTrackDemuxer, NotifyNewOutput) are merged into 1 so that only mReceivedNewData is set to false again but MFR will
never have a chance to trigger another Update to call CancelWaitingForKey.
By refactoring the condition to resolve the WaitForDataPromise, MDSM is able to request new data and MFR is able to cancel waitingforkey then continue the flow.
MozReview-Commit-ID: 31brwzOoUvF
--HG--
extra : rebase_source : 8caf8b426dd693e2806ebb8a059a3b91026d7f52
There are two places where I have to cache the status of MayHaveOpacityAnimation
and MayHaveTransformAnimation. First place is in |nsIFrame:init()| where an
element is associated with a frame. Second place is in
|KeyframeEffectReadOnly::UpdateEffectSet()| where the script can add animations
on element.
btw I keep the original two flags of MayHaveOpacityAnimation and
MayHaveTransformAnimation in EffectSet because there is no guarantee that
an element has been associated with a frame when we call to |UpdateEffectSet()|.
But we still want to keep the benefits that we can quickly look up
MayHaveOpacityAnimation or MayHaveTransformAnimation. So I keep them in
EffectSet and transfer the status into nsIFrame when we bind an element
to a frame in nsIFrame:Init().
MozReview-Commit-ID: JDwyAQQTKA7
Since we don't want to treat NS_BASE_STREAM_CLOSED as abort or error, let's just
treat it as success to simplify the call flow.
MozReview-Commit-ID: 1Fubaq6lfAq
--HG--
extra : rebase_source : b9168704aa618eca553d96770e3256aadcc4b925
Instead of doing dispatch inside MediaResourceCallback::NotifyDataEnded(),
we let the callers decide whether to call the function synchronously. This is required
by ChannelMediaResource::CacheClientNotifyDataEnded() which will run off the main thread.
MozReview-Commit-ID: IzUYw8QMZbD
--HG--
extra : rebase_source : b888049d5b999a37515f00e52ae02dcf17f227e8
extra : intermediate-source : 7b660cd9b9fbb1a00e427b8e9074c9b736a80ae9
extra : source : cc055c39bd9fbbeb4354bbbebe0c46512be6e3a3
The VP9 decoder following a flush will often return MF_E_NOTACCEPTING. Attempting to request an output would cause the error MF_E_TRANSFORM_NEED_MORE_INPUT to be returned. We can simply feed the decoder with the compressed sample.
MozReview-Commit-ID: GUNniZsOKWr
--HG--
extra : rebase_source : 047a0d4dbea16e6f3d7e2269432ed3a591387dbe
Before this change, the test calls getAnimations() after changing animation
duration. Unfortunately it was wallpapering what's going on there actually
since getAnimations() flushes pending styles. This patch drops the
getAnimations() call and makes it clear how many restyles happen there.
MozReview-Commit-ID: A0a5MlTyBnD
--HG--
extra : rebase_source : cc20d2c6945f81f72c753137441b8d84ff52ff63
Summary:
We currently implement no platform authenticators, so this would always
resolve to false. For those cases, the spec recommends a resolve timeout
on the order of 10 minutes to avoid fingerprinting.
A simple solution is thus to never resolve the promise, otherwise we'd
have to track every single call to this method along with a promise
and timer to resolve it after exactly X minutes.
A Relying Party has to deal with a non-response in a timely fashion, so
we can keep this as-is (and not resolve) even when we support platform
authenticators but they're not available, or a user rejects a website's
request to use them.
Reviewers: jcj, smaug
Reviewed By: jcj, smaug
Bug #: 1406468
Differential Revision: https://phabricator.services.mozilla.com/D217
This follows from the previous patch; these values feed into UpdateMinMaxScale
as well, which explicitly wants to use floats, so there's no point in creating
doubles. The source of this information is also a float-based matrix.
MozReview-Commit-ID: LPk4Xm9AaJJ
--HG--
extra : rebase_source : d7714755fb1078880133d6f044cc9bc7743439ee
Skip files under intl/icu/ because they're imported from third party.
DONTBUILD because this is a whitespace-only change.
MozReview-Commit-ID: GSd6oeFSTO7
--HG--
extra : rebase_source : 38c20bf6099c18b2fcb4c324d470b279addf8891
This patch uses MozURL in ServiceWorkerRegistrar and in DBScheme to obtain the
origin of a URL. This is safe because the URL is always http/https/ftp.
It also changes the serialization of Principal in nsJSPrincipals in order to
pass the originNoSuffix together with the OriginAttributes and the spec.
The core of this change is in gfxContext.*:
- change gfxContext::CurrentMatrix() and gfxContext::SetMatrix() to
return and take a Matrix respectively, instead of converting to
and from a gfxMatrix (which uses doubles). These functions therefore
will now match the native representation of the transform in gfxContext.
- add two new functions CurrentMatrixDouble() and SetMatrixDouble() that
do what the old CurrentMatrix() and SetMatrix() used to do, i.e.
convert between the float matrix and the double matrix.
The rest of the change is just updating the call sites to avoid round-
tripping between floats and doubles where possible. Call sites that are
hard to fix are migrated to the new XXXDouble functions which preserves
the existing behaviour.
MozReview-Commit-ID: 5sbBpLUus3U
There's nothing preventing the flat tree from changing while the document
doesn't have a shell. In that case, we really really don't want to lose track
of elements with stale style data, since then we'll mess up.
It's ok to _not_ clear the style data when the document goes into the BFCache
though, because the document is thrown away if other document runs script and
touches the cached DOM.
MozReview-Commit-ID: 4W3xDAnnLPL
Otherwise we may inappropriately style it or what not. This asserts with the
patches of bug 1414999 plus the cleanup of bug 1418456, since we no longer do
StyleNewChildren (which walks over the flattened tree children).
Too bad that GetXBLBinding is a virtual call in Gecko, probably can do just
MAY_BE_IN_BINDING_MGR...
MozReview-Commit-ID: CNU0YdKeaR0
They're useless now, provided we remove the hack to not traverse XBL-bound
elements on initial styling.
This also allows us to get rid of the fallback case.
MozReview-Commit-ID: AvBVdyF1wb6
If the element has no data, it's pointless to reconstruct frames on it, or post
a reconstruct. There's no need to particularly force to have data in this case.
MozReview-Commit-ID: Lo24XQfLN0j
We not only need to care about children getting inserted in the flat tree, but
also about children moving _out_ of the flat tree.
In particular, as of right now we may leave stale data on elements when they
disappear from the flattened tree.
We're lucky enough that in 99% of the situations we enter in[1] and that clears
all the stuff, including servo data. But my assertions for bug 1414999 caught
the template / observes case.
Thus, just clear the whole bound element subtree data, and restyle it in the
end, no need for StyleNewChildren. This matches what we do for shadow DOM
(though in the shadow DOM case we do it async in DestroyFramesForAndRestyle).
[1]: https://searchfox.org/mozilla-central/rev/9bab9dc5a9472e3c163ab279847d2249322c206e/dom/xbl/nsXBLBinding.cpp#368
MozReview-Commit-ID: 69A0aR0AFfU
Currently we run the risk of missing MediaManager::OnNavigation() at shutdown in
some cases. When it happens, cleanup of window listeners is delayed to
MediaManager::Shutdown().
Triggering window listener shutdown through the destructor doesn't work when the
destructor is invoked by WindowTable::Clear(), as clearing out the
window listener's SourceListeners will trigger a call back into
WindowTable::Remove() to remove the now empty window listener.
This is not allowed by the hash table implementation.
This patch fixes this by changing strategy from cleanup-in-dtor to explicit-cleanup-before-dtor and making a non-clean state in the dtor an error.
MozReview-Commit-ID: C9FryVlv28d
--HG--
extra : rebase_source : 55ccf96b15eb3261d5176364e6952f51415bc668
This delays setting sInShutdown (renamed to sHasShutdown for better semantics)
until all that remains of shutdown is to shut down the media thread.
From JS this is no change as JS cannot run until Shutdown() is done.
The difference is that we let members and still-active listeners get destroyed
and cause any members that are media-thread only (in this case devices), to shut
down before the thread goes away.
MozReview-Commit-ID: 5NTWwh8Umn8
--HG--
extra : rebase_source : f6b508abc95434f027a6544fdac53949138764da
If the image request gets redirect on loading, HTMLImageElement.currentURI
(which corresponds to nsIImageLoadingContent.currentURI) would return the
original URI before redirect, making "Save Image" in the context menu use
incorrect URI and filename. Use currentRequestFinalURI instead to get
redirected URI.
MozReview-Commit-ID: Bd7Q36sH93b
--HG--
extra : rebase_source : b88ccf98bc2a41aac007d79060424eaa2c2aca88
ImageLoadingContent.currentURI returns the "URI" of currentRequest, which is
the URI used to start that request. Some consumers need to know the final URI
of that request instead.
If the image request gets redirected on loading (e.g. an add-on intercepts the
request), currentRequestFinalURI will be the redirected URI, while currentURI
would be the original URI before redirect.
MozReview-Commit-ID: 9lX063uAIp1
--HG--
extra : rebase_source : 6e9752b4df52e3874815557fe727c3fe94af2902
If the image request gets redirect on loading, HTMLImageElement.currentURI
(which corresponds to nsIImageLoadingContent.currentURI) would return the
original URI before redirect, making "Save Image" in the context menu use
incorrect URI and filename. Use currentRequestFinalURI instead to get
redirected URI.
MozReview-Commit-ID: Bd7Q36sH93b
--HG--
extra : rebase_source : 5a1cc56554d1429f3c5af1c8cecaa1d72471ed21
ImageLoadingContent.currentURI returns the "URI" of currentRequest, which is
the URI used to start that request. Some consumers need to know the final URI
of that request instead.
If the image request gets redirected on loading (e.g. an add-on intercepts the
request), currentRequestFinalURI will be the redirected URI, while currentURI
would be the original URI before redirect.
MozReview-Commit-ID: 9lX063uAIp1
--HG--
extra : rebase_source : 91451128abc5c3f29c11d3cabfc98cde6c440ea6
The "current URL" in the spec:
https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-currentsrc
maps to imgIRequest.URI, not currentURI.
Rename imgIRequest.currentURI to finalURI to prevent such confusion.
MozReview-Commit-ID: CjBh2V4z8K9
--HG--
extra : rebase_source : 01277d16ef12845e12cc846f9dd4a21ceeca283b
Even with this patch, in Gecko getUnanimatedComputedStyle flushes pendings
styles somehow. Also in Stylo the function flushes pending styles if the
target element hasn't yet styled or Servo style data has cleared for some
reasons (e.g. the element is in display:none subtree).
MozReview-Commit-ID: HCizzM0JnFz
--HG--
extra : rebase_source : 81f130f35794d6ddcf6b7e7f70566d521ea63d31
Before this patch, 'content: ""' was applied to the ::before element after
calling getUnanimatedComputedStyle() with '::before' argument so the function
was called for inexistent pseudo element.
Gecko generates ::before and ::after element even if the content property for
the element is none (bug 1387931), so Gecko is not affected by this patch at
all. Whereas Stylo has returned the parent style as the pseudo style for the
inexistent pseudo, it will be fixed by bug 1418867 and a test case will be
added in that bug since SimpleTest does not have todo for doesThrow().
MozReview-Commit-ID: 7uJcCrtu9ke
--HG--
extra : rebase_source : 96f3d1428323e8a7d96b0dee3e7256360251e555
Before this patch, we had been only testing the null element case.
MozReview-Commit-ID: DYB8DtGBIwC
--HG--
extra : rebase_source : c0b8774f795c64b6d525820e6737ed3beed2dda0
This also changes URIUtils.cpp:DeserializeURI() to use the mutator to instantiate new URIs, instead of using their default constructor.
MozReview-Commit-ID: JQOvIquuQAP
--HG--
extra : rebase_source : e146624c5ae423f7f69a738aaaafaa55dd0940d9
When paintingSuppressed flag is true, paint_listener.waitForPaints() defers the
waiting paint to the next tick. The paintingSupressed flag is set when pres
shell is initialized and at that time if the document has not been loaded yet,
a timer is created to clear the flag after nglayout.initialpaint.delay
elapsed. And when the timer is fired, the flag is cleared, but if there is
still pending reflow, it's not cleared.
So what happened in the failure case;
1) In the first promise_test we wait for document load
2) The paintingSuppressed flag is set in the first promise_test and create the
timer
3) When the document has been loaded but the timer has not yet been fired,
start test refresh mode and create an element in the subsequent promise_test
4) Creating the element triggers a reflow
5) waitForPaints() is called
6) The timer is fired, but there is a pending reflow, so skip clearing the flag
7) Now it's in the test refresh mode, the pending flow will never be processed
until some triggers happen (i.e. mouse movement, calling
advanceTimeAndRefresh, etc.)
8) The test is timed out
MozReview-Commit-ID: 5fLn9SNHp1J
--HG--
extra : rebase_source : 3115a5d5ac1405f18efde7ade1fb9738858c518f
This is required now that the reporter is async.
MozReview-Commit-ID: djvw9v7kuj
--HG--
extra : rebase_source : d105f972eda0d59212b8094150762e44aa8c582d
This is primarily to improve code readability of the reporter's lifetime.
Creation of the singleton was hidden away in GetRecorders().
Both creation and destruction is now more explicit in {Add|Remove}MediaRecorder.
MozReview-Commit-ID: CqxgPQ1JptK
--HG--
extra : rebase_source : 5af3052911cd346c7d1221baf653f0b046304ed0
This flag would be used to help us decide whether website could be allowed the autoplay.
The media related implementation would be implemented in bug1382574.
MozReview-Commit-ID: GGIauBufs5A
--HG--
extra : rebase_source : c407ceed311fc3fb0140e5da44fd69e457a5098f
1. move all checks to CanActivateAutoplay()
2. don't cache the pref's value in advance, it might cause wrong result
if user changes pref after media was binded to tree.
MozReview-Commit-ID: 3BeOeaq9wGa
--HG--
extra : rebase_source : 74085dce2852d0a608f6455bd0b9337b8223fa20
We disabled these tests on linux/debug last week and that seems to effectively
avoid shutdown hangs on those platforms. This expands the scope of the disabling
to linux/asan, where we still see intermittent hangs.
This needs to dumb down the parsing in order to match what we do in Gecko and
pass more tests.
The remaining tests are just because of calc() in media queries and "or" media
expressions.
MozReview-Commit-ID: CXGdYVbojBL
A ghost window is a window that is:
a) detached
b) we think it should have gone away
c) it has been in that state for a while
Right now, criterion b holds if the detached window does not have the
same eTLD as any window that is not detached. However, this can cause
false positives when a page leaks a cross-origin iframe.
This patch changes criterion b to be that it holds if the window is
not in the same tab group as any non-detached window. This should
match better with the goal of ghost windows, which is to identify when
pages don't go away after their tab is closed.
MozReview-Commit-ID: GG8d0WkXDUt
--HG--
extra : rebase_source : a9464b91bf565e2fe46062b4ce3b591b10e38f25
I used ReportToConsoleNonLocalized to make the patch upliftable.
MozReview-Commit-ID: LsOBOfzU9Hr
--HG--
extra : rebase_source : 77005687c079b96f86f7b70ad155b4e5d1faed88
This patch implements HTMLMediaElement::GetEventTargetParent and set
aVisitor.mCanHandle to false to mouse/touch/pointer events, when
the media control is present. This tells the event dispatcher that
these events are supposed to be handled exclusively by the
videocontrol binding within the media element, and should not
dispatch nor consumed by the content.
MozReview-Commit-ID: BXWZX9SYsuC
--HG--
extra : rebase_source : 5d6633a2e1a456d2d619b6f68498065d94c68c40
There's nothing preventing the flat tree from changing while the document
doesn't have a shell. In that case, we really really don't want to lose track
of elements with stale style data, since then we'll mess up.
It's ok to _not_ clear the style data when the document goes into the BFCache
though, because the document is thrown away if other document runs script and
touches the cached DOM.
MozReview-Commit-ID: 4W3xDAnnLPL
There are currently two types of sinks for a MediaStreamTrackSource.
Actual MediaStreamTracks and HTMLMediaElement::StreamCaptureTrackSource.
A source needs actual tracks as sinks to not stop() the underlying source.
A StreamCaptureTrackSource, however, should not count toward keeping a source
alive (otherwise HTMLMediaElement.mozCaptureStream() would prevent track.stop()
from working on the track feeding the media element).
MozReview-Commit-ID: 9MBAyZFZUIQ
--HG--
extra : rebase_source : a73f182b95281baf4f44f7ae82158e4a6bce42eb
This is a drive-by fix in that it is not directly related to what the bug is
solving. However, making HTMLMediaElement register as a sink is important,
and pairing it with the WeakPtr<Sink> patch reduces risk greatly.
MozReview-Commit-ID: 7pMDw3MG0ZB
--HG--
extra : rebase_source : e2f2b3a12b9921373518d94a083adda23bfe853b
Users can block the overriding of shortcuts using the permissions tab of the page info dialog, as with other permissions. Site permissions also allows the use of permissions.default.shortcuts to block overriding shortcuts for all sites.
JW Wang
Brindusan Cristian
Emilio Cobos Álvarez
Sebastian Hengst
Nika Layzell
Boris Zbarsky
Andrea Marchesini
Jean-Yves Avenard
Michael Froman
Kilik Kuo
Noemi Erli
Ya-Chieh Wu
James Cheng
Tom Ritter
arthur.iakab
Hiroyuki Ikezoe
Kevin Chen
Edgar Chen
btara
Jon Coppeard
Tim Taubert
Coroiu Cristina
Nicholas Nethercote
Alfredo.Yang
Csoregi Natalia
Christoph Kerschbaumer
dluca
Andreea Pavel
Kartikaya Gupta
Ting-Yu Lin
Joel Maher
Jonathan Watt
shindli
Henri Sivonen
Jonathan Kew
Bill McCloskey
Phil Ringnalda
Ryan VanderMeulen
Kyle Machulis
Chris Peterson
Jason Orendorff
Gijs Kruitbosch
Andreas Pehrson
Samael Wang
Margareta Eliza Balazs
Tim Huang
Valentin Gosu
Tiberius Oros
Alastor Wu
Sylvestre Ledru
Geoff Brown
Ben Kelly
Chung-Sheng Fu
Narcis Beleuzu
Chris Pearce
Edouard Oger
Andrew McCreight
Masatoshi Kimura
Daosheng Mu
Timothy Guan-tin Chien
Munro Mengjue Chiang
Ciure Andrei
Byron Campen [:bwc]
Brad Werth
Luca Greco
Jan de Mooij
Neil Deakin