The dom.forms.autocomplete.formautofill check in nsContentUtils::InternalSerializeAutocompleteAttribute
will control if values other than "on" and "off" are supported.
MozReview-Commit-ID: 48X3OzvuOpV
--HG--
rename : dom/html/test/forms/test_input_autocomplete.html => dom/html/test/forms/test_autocomplete.html
extra : rebase_source : b759672d2e9ef3b1e63fd999d149cf753df60539
It's not necessary to hide the implementation of the property since nsContentUtils::InternalSerializeAutocompleteAttribute
already does a pref check to decide whether values other than "on"/"off" are supported.
MozReview-Commit-ID: 4yG1tfOJavX
--HG--
extra : rebase_source : b58e600aab991eebf1c3f732fb432fb0aa6d47d7
Per https://github.com/w3c/webappsec-secure-contexts/issues/42, the
section considering the window opener when calculating secure context is
to be dropped. Firefox already uses "isSecureContextIfOpenerIgnored" in
most places as this is the actual behavior we want. This patch aligns
with the upcoming spec changes by ignoring the window opener. We also no
longer have to keep information about whether our opener was secure as
that no longer factors in our calculations.
--HG--
extra : rebase_source : 3d7fa73976571f357e84e369093aecfc10c5872e
extra : amend_source : ca86714f357b653577f3186b6312bfa00f1f45b9
Basically, this patch does three things as following:
1. Limit the scope of service worker to the controlling document so that it
won't influence other tests.
2. Ensure to catch the channel to controlling document if it's an internal
redirect. We should get two channel with the response.URL(The first one for the
service worker and the second one for the controlling document). Distingulish
them by the order.
3. Ensure to get the controller change event after posting the "claim" message
to the service worker.
--HG--
extra : rebase_source : fb2395fb6dce59ae0fd49b0b915aca52c78206e0
Previously we used the MozPromise interface for calling an async-message over
IPC with a reply. Unfortunately, MozPromise processes the reply asynchronously,
potentially allowing other IPC messages to be processed before the `->Then`
callback is processed.
In the original CreateWindow patch I tried to work around this by setting the
target of the `->Then` callback to be StableStateEventTarget. This worked,
however as it isn't safe to run scripts etc. in the stable state, we instead
tried to exit the nested event loop immediately after the runnable ran, and then
performed processing of the reply.
Unfortunately, this bug exposed a problem with that design. If we have multiple
nested event loops then we cannot guarantee that we'll exit the nested event
loop immediately after recieving the `->Then` callback, which meant that we
could still process other IPC messages before we processed the CreateWindow
reply.
The fix to this was to add a new API to allow passing callbacks directly into
IPC send methods, ensure that those callbacks are called in IPC order, and
fully process the CreateWindow reply in the callback, rather than waiting for
the nested event loop to exit.
MozReview-Commit-ID: D6zaMJRxhXd
Currently if you write an async IPDL method which has a return value, we expose
a SendXXX method which returns a MozPromise. This MozPromise can then be
->Then-ed to run code when it is resolved or rejected.
Unfortunately, using this API loses ordering guarantees which IPDL provides.
MozPromise::Then takes an event target, which the resolve runnable is dispatched
to. This means that the resolve callback's code doesn't have any ordering
guarantees relative to the processing of other IPC messages coming over the same
protocol.
This adds a new overload to SendXXX with two additional arguments, a lambda
callback which is called if the call succeeds, and a lambda callback which is
called if the call fails. These will be called in order with other IPC messages
sent over the same protocol.
MozReview-Commit-ID: FZHJJaSDoZy
This restriction was put in place back when we automatically added
QueryInterface to all rootmost non-abstract interfaces. At the time, we needed
to make sure it did NOT end up on EventTarget, because then webidl quickstubs
would replace the QI impl on non-webidl EventTargets with the WebIDL one, which
would not work for them.
Since then, we have removed WebIDL quickstubs and we now explicitly list which
interfaces get QueryInterface, so this check is no longer needed.
MozReview-Commit-ID: 5B13ymdyLp3
We implemented v1.1 of the U2F specification, which wasn't publicly published
at the time. Bug 1276968 was to come back and fix those links, so here it is.
MozReview-Commit-ID: 8hprQncPwcO
The difference between nsDocument::IsWebAnimationsEnabled and
nsContentUtils::AnimationsAPICoreEnabled is that the former checks the caller
type and treats the preference as set for system callers which is particularly
needed for enabling things like the getProperties() API for DevTools etc.
Generally in API-facing call sites we have a JS context / CallerType and so we
want to distinguish between system callers and non-system callers. However, for
a few internal uses--specifically filling-in missing keyframes--we don't care
about the caller type and always follow the pref setting.
That may or not be quite what we want, but this patch doesn't change that except
for one call site: KeyframeUtils::GetKeyframesFromObject. This patch changes
GetKeyframesFromObject from *not* checking the caller type to checking the
caller type. That seems to be the correct behavior here since this is called
from KeyframeEffectReadOnly::SetKeyframes(JSContext*, JS::Handle<JSObject*>,
ErrorResult&) (i.e. a JS API-facing call site) where we *should* enable the full
API when the caller is chrome code.
MozReview-Commit-ID: FQJBk3zytwd
--HG--
extra : rebase_source : 577bca1e551e39fecfab309f64c993eba110337f
This private method DoAutoScroll() modifies aPoint inside of it, and none of
other callers (StartAutoScrollTimer() and nsAutoScrollTimer::Notify()) read
aPoint afterwards, so we make aPoint pass by value rather than pass by
non-const-reference. This is necessary for later parts.
MozReview-Commit-ID: 9PtxFXIka7X
--HG--
extra : rebase_source : 3bd47f071b3cecdc439ebc3b56c6a4f7ef56eff8
NotifyDataEnded() runs off the main thread which might set mChannelEnded
wrongly after NotifyChannelRecreated reset it on the main thread.
We should reset the flags in NotifyDataStarted() which indicate a new load has begun.
MozReview-Commit-ID: Gi6PFXwMJqc
--HG--
extra : rebase_source : 85bb2c25a55cce4b3c3f023bf4c02fe5d1de7552
extra : source : 2f8c5518bf615f9190f87032568fc53037bc6fc1
There are some works to do when we allow a stream whose download ends abnormally
to continue sharing the resource:
1. Abort Read() when download error happens. We might still have a chance to
get all the data successfully. However, it doesn't really matter since
the stream data is incomplete and we will encounter decode errors sooner
or later.
2. Update() needs to check mChannelEnded since an ended stream will not
download data needed by other streams.
MozReview-Commit-ID: LGCecQ5rpzq
--HG--
extra : rebase_source : 17a91a1cfd145344c3c0a29b80665cb99ce20746
extra : source : 0947c12b035acc9fba02e89dc87b3a17f84cf2e5
Since NotifyDataEnded() run its code asynchronously, it is possible that a new
channel is created and NotifyDataStarted() is called before NotifyDataEndedInternal()
has a chance to run. We check the load ID to exit the function if necessary.
We also need to fix data races when running NotifyDataEndedInternal() off the
main thread in next patches.
MozReview-Commit-ID: IIAc7dxHike
--HG--
extra : rebase_source : 58e45f924058a986b8d86bfaeff2791ee8a5f4bc
extra : intermediate-source : b2a7fa7514723e214b8da40cfc0ec40b1de9a345
extra : source : 1ff93dc8f8c451b804133c780cedef2ee3d348e5
It is a good practice to make the call flow simplier. It also makes
the changes in the following patches easier.
MozReview-Commit-ID: CKjRBReLFro
--HG--
extra : rebase_source : 1903b0648b718541af9f796dfa664209552f47d2
extra : intermediate-source : 12ffa8e5cb637dbb4d425d6b2ddae6c7574f767a
extra : source : a1d92c67ec461f8fda88546fd1f0be0c00c39dc7
Previously this was safe, as the synthesized mouse event would be processed in
the child process, updating the focus state, in order - before the content
process would try to check its focus state. Now, thanks to multiple event queues
work, this isn't guaranteed.
This patch just adds retrying to the logic, so we retry up to 10 times, 100ms
apart. This should ensure that we don't incorrectly detect a test failure
intermittently.
MozReview-Commit-ID: J4uzl9jeafC
Add a new |offerer| field to RTCStatsReport.
Based on offerer, label the local sdp as offer or answer.
Based on offerer, label the remote sdp as offer or answer.
MozReview-Commit-ID: 4jdWP8tpr9w
--HG--
extra : rebase_source : 5724645ef8e39c2af0c5fccf7d7872ee2cb437b5
This is a speculative "fix" for a chronic shutdown hang in mochitest-media-e10s-2,
generally reported in bug 1411358. Experiments on try suggest that the hang
occurs much less frequently when these tests are not run.
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
The MediaKeys status inside a HTMLME cannot be reflected correctly if the mSetCDMRequest is disconnected in HTMLME::ShutdownDecoder.
This may happen when a page calls load() or sets new src right after setting MediaKeys to null.
MozReview-Commit-ID: 3BZOmw7BNFO
--HG--
extra : rebase_source : f06ae54944133e8e48471e71f0bb8fe46290cca8
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
Hiroyuki Ikezoe
Daosheng Mu
JW Wang
Edgar Chen
Thomas Nguyen
Alfredo.Yang
Gabriele Svelto
Tim Taubert
shindli
Matthew Noorenberghe
Kate McKinley
Andrea Marchesini
Ciure Andrei
Tom Tung
Adam Gashlin
Coroiu Cristina
Emilio Cobos Álvarez
Cervantes Yu
Jonathan Kew
Jesse Schwartzentruber
Tiberius Oros
Nika Layzell
Brindusan Cristian
Cosmin Sabou
Tooru Fujisawa
Boris Zbarsky
J.C. Jones
Jon Coppeard
Margareta Eliza Balazs
Brian Birtles
Ting-Yu Lin
Fernando Jimenez Moreno
Olli Pettay
Jan de Mooij
Sebastian Hengst
Jeff Gilbert
John Dai
Michael Froman
Ben Kelly
Mats Palmgren
Geoff Brown
Csoregi Natalia
Gurzau Raul
sotaro
Kilik Kuo
Munro Mengjue Chiang
Jean-Yves Avenard
Noemi Erli
Ya-Chieh Wu
James Cheng