Various web authors have expressed desire to know in advance whether autoplay
will work.
They want this in order to avoid paying the price for downloading media that
won't play. Or they want to take other action such as showing a poster image
instead.
This is of particular interest to Firefox, as we're planning on showing a
prompt to ask the user whether they would like a site to play. If sites want to
determine whether they can autoplay but avoid the prompt showing, they won't be
able to just call play() in Firefox and see whether it works, as that would
likely show the prompt if the user doesn't already have a stored permission.
We've been working out a spec here:
https://github.com/whatwg/html/issues/3617#issuecomment-398613484
This implements what is the consensus to date there;
HTMLMediaElement.allowedToPlay, which returns true when a play() call would not
be blocked with NotAllowedError by autoplay blocking policies.
MozReview-Commit-ID: AkBu0G7uCJ0
--HG--
extra : rebase_source : 3f31db79aa1e570fdd9fc7062d0ddac7c96a8931
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
It's currently only accessible on XULDocument and XULElement, but that makes porting existing
JS to run in an HTML document inconvenient. We could alternatively change calling JS, but
this can be easily moved and exposed in chrome contexts.
MozReview-Commit-ID: JitYET20NSE
--HG--
extra : rebase_source : 75d823c688cba8d84dc19705e83284be383962f2
Also remove overload for XULDocument::Persist and the implementation
of XULDocument::DoPersist, since there's only one remaining caller.
MozReview-Commit-ID: CPaTdFJ4GOx
--HG--
extra : rebase_source : b0fdfbdab204f787349b3284fc8c73c4aa799d66
The CSSAnimation and CSSTransition interfaces are only needed to represent CSS
animations and CSS transitions returned by the
{Document,Element}.getAnimations() API.
Bug 1471814 introduced the dom.animations-api.getAnimations.enabled pref but
neglected to guard the CSSAnimation and CSSTransition interfaces behind this
pref, leaving them guarded by the dom.animations-api.core.enabled pref instead.
This patch updates the pref used to guard these interfaces so that when we turn
on the dom.animations-api.core.enabled pref by default we don't also end up
shipping these interfaces.
MozReview-Commit-ID: GjfvOltxlJy
--HG--
extra : rebase_source : 254cde7e9975d83b4ac94567725e6475f344e61d
At some point the type of the ssrc field changed to an unsigned long.
MozReview-Commit-ID: BmGXAaKQfim
--HG--
extra : rebase_source : b749797b5001b2ef867a239f61d22c69d5d22408
This is probably the last thing we will ship since it needs the most spec work.
MozReview-Commit-ID: LLmDBLCsCBJ
--HG--
extra : rebase_source : c06752c9201a9ede87e1ac200ab12577bf784ce6
This feature should not be shipped until the various definitions of addition for
each additive property are properly specified.
Unlike other patches in this series, compositing is not frequently used
internally (e.g. by DevTools etc.) so there is no need to enable this by default
for system code.
Also, it turns out we have inadvertently been shipping part of this feature for
some time now. The next patch in this series will add tests for that case and
disable that part of the feature (a suitable intent to unship will follow). This
patch merely adapts and extends the existing tests without affecting the surface
area covered by the combination of the newly-added pref and the existing
dom.animations-api.core.enabled pref.
MozReview-Commit-ID: Htr6mlyCBav
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_compositing.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_compositing.html
extra : rebase_source : 7715a25e59568eb122ba3f7dbd2c2b2ffdd19954
We don't intend to ship this in the near future until the integration with
AnimationWorklet is clear (although we might ship a read-only version).
That said, we use this feature extensively internally (e.g. in DevTools etc.) so
we enable this feature for system callers.
MozReview-Commit-ID: AhB7ZmU1Xzw
--HG--
extra : rebase_source : 630d7dc56b44a9261bb34aa5417cb9b7050efba4
Link to the standard: https://webaudio.github.io/web-audio-api/#dom-audioparam-setvaluecurveattime
MozReview-Commit-ID: 8GwaIbQkfr2
--HG--
extra : rebase_source : aa8dd5e653de51768ff81d855fe1b8b398baa586
extra : intermediate-source : 9d34c85e0ec166fb7a117b2a85ca7cd4e98b1ceb
extra : source : d752fc72a9a35fdc0ce7b8bce94b29149eaf7639
The following was removed:
- the main meat of the overlays and interface in XULDocument
- all overlay observers and forward references
- the notion of a master document
- XUL overlay provider
- manifest parsing of overlay attribute
- references to "overlay" atom
- restrictions on persistence (only need because of overlays)
- unused code that the above referenced
I also attempted to update comments that referenced overlays, but there is still
some work to be done here.
MozReview-Commit-ID: 8lrirzcgSuJ
--HG--
extra : rebase_source : 25b4e1d3fb2af6f02d894887271fd345c9c2083b
window.event is set on the wrong window when the target and the
callback are from different realms and the callback is an XPCOM
callback.
MozReview-Commit-ID: HXeUIicdMuT
--HG--
extra : rebase_source : 978a3fecf87e1ac4414ec0ea93335796bc24951a
window.event is set on the wrong window when the target and the
callback are from different realms and the callback is an XPCOM
callback.
MozReview-Commit-ID: HXeUIicdMuT
--HG--
extra : rebase_source : 5852093c015844cf3cc49dcd7fe71c9ea881eef9
window.event is set on the wrong window when the target and the
callback are from different realms and the callback is an XPCOM
callback.
MozReview-Commit-ID: HXeUIicdMuT
--HG--
extra : rebase_source : 9679d42cc9df899e2208a3cb72e14fdaabbcad8c
Sometimes when video is playing, a preroll ad plays, and that may be in a cross
origin iframe. If autoplay media is disabled, we require a user gesture in a
document before playback in that document is permitted, and we require each
origin to be gesture activated separately. So in the cross origin preroll video
add case, then the user will have to click once to unblock playback for the
cross origin ad, and then once the preroll ad finishes, the user will have to
click again to activate playback of the same origin content video.
This is a bad user experience.
So we should instead make gesture activation propagate up the doc tree
irrespective of crossing origins. This way, when the user clicks to activate,
all documents in that tab are also also effectively gesture activated, and so
can autoplay.
MozReview-Commit-ID: 1HZQ5zkubR
--HG--
extra : rebase_source : d6b75732548cb1d73b9f82dce60a5e6e97d1da14
Make document.domain non-nullable, to conform to the HTML spec.
MozReview-Commit-ID: B1YuQekBgZD
--HG--
extra : rebase_source : 00999e16549e62c783f06f61c62000ab7677cf1d
I've made the returned object from .bounds not live. If that's not OK, I'll
resurrect DOMBounds (removed in a previous patch). This also forces
DOMQuad.toJSON() to only return the points.
MozReview-Commit-ID: 10TY5oJUmTN
--HG--
extra : rebase_source : f965bd0593b512ec57ffc5268eecf3b4fe8e820a
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
Cache AccessibleNode and make it able to operate the same instance by nsINode::GetAccessibleNode
--HG--
extra : rebase_source : 063eec8658af020f5408260d7d581ee76a04bd37
These properties are unused from C++ apart from webidl bindings and the
FakeTreeBoxObject implentations in comm-central are throwing stubs. But
they're used in JS. They are safe to remove from nsITreeBoxObject but we need
to keep an implementation webidl can call into. Properties in this bucket:
selectionRegion, ensureCellIsVisible, scrollToRow, scrollByLines,
scrollByPages, getRowAt, removeImageCacheEntry.
These properties are not used from either JS or C++, and hence can be
removed from both nsITreeBoxObject and TreeBoxObject.webidl. Properties in
this bucket: scrollToCell, scrollToColumn, scrollToHorizontalPosition,
invalidateColumnRange.
Deleted the old Chrome DataTransfer constructor because it was only used
for some tests which can be easily changed. Added a new constructor that
is not Chrome Only.
MozReview-Commit-ID: HjcgafSiWfM
The last remaining user is already turned off and being removed
in bug 1444395 so that we can finally remove this unsafe code and
sleep a little better knowing that XSS through markup injections
will be impossible in chrome contexts.
MozReview-Commit-ID: KcZq8fRPiD4
--HG--
extra : rebase_source : 5def3abb50ed8f1b43e17072088e38a44394488b
I've made the returned object from .bounds not live. If that's not OK, I'll
resurrect DOMBounds (removed in a previous patch). This also forces
DOMQuad.toJSON() to only return the points.
MozReview-Commit-ID: 10TY5oJUmTN
--HG--
extra : rebase_source : ab209d584390c584aa0d0814b4dd2bbf48c6cca3
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 97e9386cfb17319242913d28117c8b1b8b6fbbbe
the id was a b2g feature only settable via chrome privd xhr and is no
longer active in the code base
MozReview-Commit-ID: 84GPNvhvjNb
--HG--
extra : rebase_source : ab5c2229b98e1407b8b74ef2ee00dcfea45e046a
This check is already done by the dictionary init method. This function just
makes us do extra non-spec get operations.
For now this introduces more failures due to bug 1419323 and the spec issue at
<https://github.com/whatwg/html/issues/3580>. The tests testing for that stuff
were passing due to exceptions getting thrown from CheckLifeCycleCallbacks.
1. Add AddressErrors in PaymentRequest.webidl.
2. IPC for passing AddressErrors.
3. Getters for AddressErrors in nsIPaymentDetails.
--HG--
extra : rebase_source : 64c57003d57e064b5284cc64447c0c0740f16121
This patch creates a chrome-only method
customElements.setElementCreationCallback() so that custom elements migrated
from XBL bindings doesn't have to be define()'d on document loading. With this
method, we will set callbacks and the platform will get back to us when it
encounters a matched custom element type -- and the callback will load the
relevant script.
It's important to note that the callback runs after construction of the first
element; it will be upgraded when it's being appended.
MozReview-Commit-ID: 80z72zwXRlf
--HG--
extra : rebase_source : 826188e56bb0b167d1e5bafb7d2a487a32bd9dfa
The aim of those changes is to be incubated in the WICG.
MozReview-Commit-ID: K93xiTod6tw
--HG--
extra : rebase_source : 788122a69b6cab96bab9c2ae6e8cdf7c61d4ed07
The aim of those changes is to be incubated in the WICG.
MozReview-Commit-ID: 5wEUnWz8i7kBug 1280613
--HG--
extra : rebase_source : 4360d2c34025bf3c87fff49f0e2aa01975fff15b
We can't remove navigator.javaEnabled() entirely because that would break any web content that tries to call the function.
MozReview-Commit-ID: KIOBrZuMu9r
--HG--
extra : rebase_source : 112ec5308d59e8d12a8ea540784ea157e575d09c
extra : intermediate-source : e9b145757c2f27440749408d9de31df7b5d60ff8
extra : source : 5fe4a7a8723bbd9cd954905cbf3937f45706d660
extra : histedit_source : a62c9571a53a834ef15778a01cb993d7e8dc3daa
I can land the removal behind a pref first if you want and all that instead.
Again, this doesn't remove the internal usage for getComputedStyle (yet).
MozReview-Commit-ID: LA157ohfLhu
It's been removed for a while on Nightly without any known regressions. This
gives us a full beta cycle of telemetry and two nightly cycles without the API
before shipping.
This only removes the API, followup work will replace serialization by Servo's,
and remove the remaining DOM interfaces.
MozReview-Commit-ID: 2m1taYg5xEr
By doing this we will have all the KeyframeEffect* related code in
KeyframeEffectReadOnly.{h,cpp} so we can rename them to KeyframeEffect.{h,cpp}
in the next patch and make it easier to examine the history for the bulk of this
code.
The added [HeaderFile] annotation will be removed in a subsequent patch in this
series.
MozReview-Commit-ID: Fxk6fPukgAS
--HG--
extra : rebase_source : 0bb0f846aba69e2b79724adb3148948317667eae
It might seem a bit odd to move the setters to the read-only class that we are
ultimately planning to drop but the reason for doing this is that
KeyframeEffectReadOnly.cpp has a *lot* more code than KeyframeEffect.cpp.
In order to simplify code archaeology we take the following approach:
1. Move code from KeyframeEffect.{h,cpp} to KeyframeEffectReadOnly.{h,cpp}.
2. Delete KeyframeEffect.{h,cpp}.
3. Rename KeyframeEffectReadOnly.{h,cpp} to KeyframeEffect.{h,cpp}.
Note that at least steps 2 and 3 must be performed in separate patches as
mercurial does not successfully track renames when the target name already
exists.
MozReview-Commit-ID: LwJoxGJitKR
--HG--
extra : rebase_source : ae437c6e74435b983c7390df301055472fa3c4ff
None of the C++ callers of RemoveSelectionListener care about whether the
listener was already-added, and the only JS caller is in a test and knows the
listener was added. So the behavior change to no-op instead of throwing when
trying to remove a nonexistent listener is OK. Furthermore, the removal is
null-safe, so there's no point to explicitly failing if null is passed (which
it never is).
Since content can't directly add selection listeners, we can just use an
infallible append instead of returning errors callers don't check for anyway.
Also, no one passes null to AddSelectionListener, so we don't have to worry
about that part.
Non functional code.
SourceBuffer.changeType allows to reconfigure a sourceBuffer so that a new codec type or new container format can be fed later.
The new code is placed behind the media.mediasource.experimental.enabled pref.
MozReview-Commit-ID: 5wj6J4uzLbA
--HG--
extra : rebase_source : b6f57246e0a4c856f6365bb0c8ec8d759a770105
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
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
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
ChildProcessMessageManager, ChromeMessageBroadcaster, and ChromeMessageSender
only implement nsIMessageSender and nsIContentFrameMessageManager. Neither one
has QIs in JS now.
ContentFrameMessageManager only implements nsIDOMEventTarget, which there are
no JS QIs for.
ContentProcessMessageManager implements nsIMessageSender and
nsISupportsWeakReference. The only JS QI for nsISupportsWeakReference is
definitely not happening on this object.
MozReview-Commit-ID: 67dxaQlhpGc
All of these have implementations that only QI to nsIDOMNode and nsISupports, and no one QIs things to nsIDOMNode in script anymore.
MozReview-Commit-ID: 2L4VCEEsLkS
BarProp, CaretPosition, Crypto, CSSMozDocumentRule, CSSPrimitiveValue,
CSSStyleDeclaration, CSSStyleRule, CSSValueList, DOMImplementation,
DOMTokenList, FileList, FrameLoader, FormData, HTMLCollection, History,
MimeTypeArray, NamedNodeMap, MutationObserver, MutationRecord, Navigator,
NodeIterator, PaintRequest, PaintRequestList, Plugin, Rect,
SVGAnimatedEnumeration, SVGAnimatedInteger, SVGAnimatedNumber,
SVGAnimatedNumberList, SVGAnimatedPreserveAspectRatio, SVGAnimatedString,
SVGLengthList, SVGNumberList, SVGPathSegList, SVGPoint, SVGPointList,
SVGPreserveAspectRatio, SVGRect, SVGStringList, SVGTransformList, Touch,
TouchList, TreeWalker, ValidityState only implement nsISupports, so
there's no point QIing them.
DOMStringMap, FrameLoader, NodeIterator, SVGPoint, StyleSheet only implement
non-scriptable non-shimmed interfaces (nsIMutationObserver, nsISVGPoint,
nsICSSLoaderObserver), so can't be usefully QIed from script.
EventSource, Notification, OfflineResourceList, Performance, Screen,
WebSocket, XMLHttpRequestUpload only implement nsIDOMEventTarget, and nothing
QIs to that in script.
PluginArray QIs to nsIObserver but doesn't expose any corresponding methods.
None of the QIs to that interface seem to be on PluginArray objects.
Range QIs to nsIDOMRange, but there is no JS code that QIs to that.
NodeList QIs to nsIDOMNodeList, but there is no JS code that QIs to that.
XMLSerializer doesn't even implement nsISupports.
MozReview-Commit-ID: Fil5cBd4K4d
We need to side-step existing cross-origin checks in Performance Timing code
when the caller is a web extension content script that otherwise has permission
to access the cross-origin resource.
MozReview-Commit-ID: 8IgtqZgPWgY
--HG--
extra : rebase_source : e8152c5d8ab32096d1ff7f97311c1b43b57c3694
This removes properties of XULElement that can easily seen to be unused, even if the attributes they control are still in use. There are other properties that may still be used once or twice, and they are not removed here.
MozReview-Commit-ID: IL6mCvtGQAG
--HG--
extra : rebase_source : 4b22b330d311ef22e3466f517c04d5a19512ab71
This attribute was added in bug 1432966 when we started sanitizing
chrome usage of innerHTML to allow devtools to use custom attributes
in React via dangerouslySetInnerHTML.
Devtools removed its usage of dangerouslySetInnerHTML in bug 1434155, so
document.allowUnsafeHTML is no longer used and can be removed.
MozReview-Commit-ID: 8xTVZDmPqRa
--HG--
extra : rebase_source : 3d427133ccb8975163b4459af57b5d96ef54c93e
1. Add "optional Promise<PaymentDetailsUpdate> detailsPromise" as a parameter
of PaymentRequest.show() in PaymentRequest.webidl.
2. Let PaymentRequest inherit from PromiseNativeHandler, and implement the
ResolvedCallback() and RejectedCallback() to handle the PaymentDetailsUpdate
promise.
3. Update PaymentRequest.show() implementation. If PaymentDetailsUpdate Promise
is not nullptr, the show request would not be transferred to chrome process
immediately until the promise is resolved/rejected.
4. Update selectedShippingOption when requestShipping is true.
5. Change the PaymentMethod id validation sequence according to the spec.
--HG--
extra : histedit_source : e591c759037cce4f66701b2faa5ecbe01c00e246
I moved the IgnoreErrors decl so it would come after the OOMReporter decl and I
could add the new conversion operator.
MozReview-Commit-ID: B1S6DXmZfvE
test_bug609794.html was testing a behavior that the method before the current
method of attaching InstallTrigger to windows depended on. We don't really
need that behavior, which is good, because this change is not producing it.
MozReview-Commit-ID: GPzif89UYYl
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : 0adb349b40a0c51bb3d8f4b9b7d98106a3929cbd
extra : source : a88d94ec010a12c1d829708aaf59a85609478477
Summary:
I'm happy to keep it around if you think having the test_mutationobservers check
is useful.
MozReview-Commit-ID: LbWvJiO9LRZ
Reviewers: smaug
Bug #: 1446597
Differential Revision: https://phabricator.services.mozilla.com/D750
This pref was introduced in case we encountered compatibility issues from
changing the return value of Animation.playState (bug 1412765). Now that the
change to Animation.playState has shipped to release channel without any known
problems we should drop this pref.
MozReview-Commit-ID: CwMWRRtIf6u
--HG--
extra : rebase_source : b26c59a51880406c2b94baad8da2eafeb3ae3202
The wpt changes come from https://github.com/w3c/web-platform-tests/pull/9920
and are needed to keep Element-classlist.html passing.
The change to testing/web-platform/mozilla/tests/dom/classList.html is pulling
those changes into our weird forked version of that test...
MozReview-Commit-ID: CvQlBRuieUY
Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
The null-checks in MatchLinks were working around code in nsDocument::Destroy
that was removed a while back in bug 341730.
MozReview-Commit-ID: 2SMmGr83GCB
Spec: https://webaudio.github.io/web-audio-api/#dom-audionode-channelcount
Google has written a web platform test this is going to be merged soon (we
currently fail it).
MozReview-Commit-ID: 1RpASaIJrhm
--HG--
extra : rebase_source : 42dc8af6e677831d70e84ffc23e738d49549c59d
extra : amend_source : b4c30805157bd9bfd06afdfc8f439fe8de1b6aae
extra : source : e7b5b629fb30c4c8b8708979e926029f4e743420
There's no standard way to create a JS error with full stack and location
information from a saved stack. Since we need this functionality in order to
reject promises with useful Error objects, this patch adds a simple helper to
make that possible.
MozReview-Commit-ID: FyGuo4UjfsQ
--HG--
extra : rebase_source : 65ef11c56f23e04ea5eeb87b972bfc8e4867fdd2
Most WebExtension APIs are async, and have fairly complicated error reporting
semantics. As a result, when we report an error, the current JS stack has very
little to do with the JS caller that triggered the error, which makes it
difficult to diagnose.
In order to improve the situation, we need to store the location of the caller
at the start of an async operation, so we can tie the error to some marginally
useful location. We don't have a reasonable way to do that now other than
proactively creating an error object when the API is called, or creating a
promise with a full async stack, both of which are too expensive.
This helper instead returns a single SavedStack frame with a given principal,
which should be considerably cheaper, and likely good enough to give a
starting point for debugging cryptic errors.
MozReview-Commit-ID: BTxhpZK9Fdz
--HG--
extra : rebase_source : 7f2c66b1dc18d4ce4c47bef2e3b9d5d3ade929aa
This patch disables device sensors except orientation by default.
It implements per-sensor prefs to disable orientation, motion, proximity and ambient light
selectively. The patch also makes the pref checks happen at runtime (versus on process
start) using Preferences::AddBoolVarCache.
The patch also removes the related Event constructors also.
MozReview-Commit-ID: EA8ARjjtlkF
--HG--
rename : dom/events/test/test_bug742376.html => dom/events/test/test_deviceSensor.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_disabled_events.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_eventctors_sensors.html
extra : rebase_source : 39da98ac9226ac727f5197d28561b0b762da06f4
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : d7c026d8a77634ef2566feba78168beb8a66a552
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 20bdd2d6f624767d919d95a6601fc1c890aadf10
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 20bdd2d6f624767d919d95a6601fc1c890aadf10
When native key event is handled by IME, we should set keyCode to 0xE5 (229,
VK_PROCESS of virtual keycode of Windows) for behaving same as the other
browsers.
This patch declares it same as other keyCode values.
MozReview-Commit-ID: 666bB1qOEgv
--HG--
extra : rebase_source : 063df635c13a416a6d89050ac45c7803a163ede0
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 5e502d5d077dd764ca1a43e7c3f06855858fe735
During a frame swap (using the `swapFrameLoaders` API on a frame loader owner),
we dispatch `pagehide` events before swapping and `pageshow` events after
swapping.
For some consumers that watch these events (such as DevTools), it would be
helpful to filter out the ones that sent because of frame swapping. This change
adds a chrome-only `inFrameSwap` property to such events so that we can tell
them apart.
MozReview-Commit-ID: QzIDuaF2zC
--HG--
extra : rebase_source : 3ac15e34c18b648c4cb060e69587e39e4ebaab60
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because the current compartment is used in the
following places and all of them are safe:
1. GlobalObject::CallerType(), that is ultimately passed to
nsDocument::IsWebAnimationsEnabled in KeyframeEffectParamsFromUnion,
to decide whether to copy mIterationComposite/mComposite to
KeyframeEffectParams.
GlobalObject::CallerType() can now be different than the target window's one,
if the caller has the system principal and the target is web content, and
in that case nsDocument::IsWebAnimationsEnabled there always returns true
while Web Animations can be disabled on web content.
honoring the mIterationComposite/mComposite properties is OK, since it just
changes the animation behavior, and this is disabled by default until
remaining spec issues are resolved.
2. GlobalObject::Context(), that is ultimately passed to
KeyframeUtils::GetKeyframesFromObject and used while extracting information
from passed-in keyframe object, with iterable/iterator protocols.
Performing that operation in the caller side is okay, since the same thing
can be done on caller, and the operation doesn't perform any GCThing
allocation on the target window global.
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because of the following reasons:
1. The target window global is used for most operation:
* KeyframeEffectReadOnly::ConstructKeyframeEffect uses the target window
global instead of current global.
* KeyframeEffectParamsFromUnion which receives `aGlobal.CallerType()`
In Xray case, Web Animations API can be disabled on web content
(currently disabled on beta/release by default), and in that case some API
won't work even it's triggered from WebExtensions, but it should be fine.
2. GetKeyframesFromObject is executed in the caller's compartment to access
the passed-in JSObject that is keyframe, with iterable/iterator protocols.
This operation doesn't perform any GCThing allocation on the target window
global.
This is the IDL added to the Web Animations specification:
5af5e276ba
Note that some of the changes in the above commit were reverted in the following
commit:
673f6fc126
A folded version of the changes:
https://gist.github.com/birtles/d147eb2e0e2d4d37fadf217abd709411
MozReview-Commit-ID: CJV7bzizXg4
--HG--
extra : rebase_source : 3b168e779883ba91c8f572478185b55013952d1a
These are cases that are implementing the "convert an exception to a Promise"
steps of the Web IDL spec. Typically the exception is thrown in the current
compartment; the Promise returned should simply match that. Otherwise we can
end up with a situation in which the promise doesn't actaully have access to
its rejection value, which will cause problems if someone uses then() on the
promise: the return value of the then() call will get a sanitized exception
instead of the real one.
We _could_ try to match the actual compartment of the exception, in theory.
But it's not clear why this would be preferable to using the current
compartment, even if there were cases in which the exception _doesn't_ match
the current compartment. Which there likely are not.
MozReview-Commit-ID: Ac2BHIHxfvY
--HG--
rename : dom/promise/tests/test_promise_argument.html => dom/promise/tests/test_promise_retval.html
rename : dom/promise/tests/test_promise_argument_xrays.html => dom/promise/tests/test_promise_retval_xrays.html
nsIDOMWindowUtils::sendKeyEvent() is already replaced with nsITextInputProcessor
for making callers set any attributes of KeyboardEvent and guaranteeing
consistency behavior with keyboard events caused by native key events. E.g.,
whether keypress event should be dispatched or not is automatically decided.
nsIFrameLoader::sendCrossProcessKeyEvent() is similart to
nsIDOMWindowUtils::sendKeyEvent() but it dispatches keyboard events in
child process directly. Currently, nsITextInputProcessor doesn't have this
feature but nobody wants/uses this feature. So, for removing actual
implementation of nsIDOMWindowUtils::sendKeyEvent(), i.e.,
nsContentUtils::SendKeyEvent(), which is shared by both
nsDOMWindowUtils::SendKeyEvent() and nsFrameLoader::SendCrossProcessKeyEvent(),
we should remove this unused API too. (FYI: it's implemented for old Fennec,
by bug 553149.)
MozReview-Commit-ID: 9n0UVo8Me8k
--HG--
extra : rebase_source : e9b117f5b9afec76e63d57ab8cd86dafb5873789
This is the IDL added to the Web Animations specification:
5af5e276ba
Note that some of the changes in the above commit were reverted in the following
commit:
673f6fc126
A folded version of the changes:
https://gist.github.com/birtles/d147eb2e0e2d4d37fadf217abd709411
MozReview-Commit-ID: CJV7bzizXg4
--HG--
extra : rebase_source : 6dc6819e158bcdd094962769096a17da6cd2026a
Summary:
This only adds the new WebIDL types but doesn't do any plumbing yet.
Bug 1406471 seems to be better suited for that.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1406458
Differential Revision: https://phabricator.services.mozilla.com/D555
It's doing casts that are bogus. We can do the same thing (only needed for
tests anyway) via a chromeonly API on DOMRequest.
MozReview-Commit-ID: 1FUPGMhBU3k
Brad Werth
Boris Zbarsky
Olli Pettay
Chris Pearce
Brian Grinstead
Brindusan Cristian
Anny Gakhokidze
Dave Townsend
Kris Maglione
Narcis Beleuzu
Emilio Cobos Álvarez
Tokio Kajitsuka
Cosmin Sabou
Arnaud Bienner
Neil Deakin
Csoregi Natalia
Brian Birtles
Nico Grunbaum
Paolo Amadini
Paul Adenot
Margareta Eliza Balazs
Emma Malysz
Bogdan Tara
Andrea Marchesini
Brendan Dahl
Henri Sivonen
Ciure Andrei
Thomas Wisniewski
Jeff Gilbert
shindli
Jonathan Kingston
Jean-Yves Avenard
Andreea Pavel
Marcos Cáceres
Sebastian Hengst
Xidorn Quan
Kyle Machulis
Blake Kaplan
Christoph Kerschbaumer
Dan Minor
Johann Hofmann
Alexander Surkov
J.C. Jones
Tom Schuster
Patrick McManus
Eden Chuang
Timothy Guan-tin Chien
Chris Peterson
Andreas Farre
Alex Chronopoulos
Bobby Holley
Robert Longson
Dão Gottwald
Kershaw Chang ext:(%2C%20Valentin%20Gosu%20%3Cvalentin.gosu%40gmail.com%3E)
Cameron McCormack
Zibi Braniecki
Coroiu Cristina
Tomislav Jovanovic
Catalin Badea
Nika Layzell
Noemi Erli
Nils Ohlmeier [:drno]
Peter Van der Beken
Kit Cambridge
arthur.iakab
Byron Campen [:bwc]
Mike Conley
Masayuki Nakano
Tim Taubert
Dorel Luca
Daniel Stenberg
Arthur Edelstein
J. Ryan Stinnett
Tooru Fujisawa
Jonathan Kew
Phil Ringnalda
Adrian Wielgosik
Tiberius Oros
Jonathan Watt