There are some platforms (e.g. iPad) which can be rotated,
but do not support the screen.orientation API. This is relevant
because iPad now supports requestFullscreen, which it did not
before.
Found while investigating #2653
Change-Id: Iacc93433aa1fb50a25d968203dc9fd4f7f16b4ae
This fixes all the license headers in the main library, which corrects
the appearance of the main license in the compiled output.
It seems that the `!` in the header forces the compiler to keep it in
the output. I believe older compiler releases did this purely based
on `@license`.
Issue #2638
Change-Id: I7f0e918caad10c9af689c9d07672b7fe9be7b2f3
@exportInterface is used by the extern generator, but ignored by the
compiler. @export should be used for shaka.polyfill.
Closes#2549 .
Change-Id: I400db152ec8ca222a45a598ab58ddfbe44552443
Also add a note to the MSE polyfill about restrictions being applied
in Player as well. We used to restrict Safari versions only in the
polyfill, and I had forgotten about the other version check.
Closes#2548
Change-Id: I4d2f319939c3a079e7f0ec7134876d91fc425bf4
We used to alias static utility methods by assigning the method itself
to a local variable. This is not allowed by the new Closure Compiler
release that we are adopting, and for good reason.
The old compiler did not understand the use of "this" in static
methods, but the new one does. And it turns out that when we start
using "this" in static methods (see #2532), aliasing the method itself
can break everything.
When you refer to "this" in a static method, it refers to the class.
This is really useful in utility classes that have private static
methods they use to perform common tasks. However, just as it ruins
the value of "this" to alias an instance method, the same is true of
an ES6 class's static method.
The fix is to always alias the class instead of the method. The new
compiler will simply not let us get away with the old way any more, so
regressions after this are unlikely.
Issue #2528 (compiler upgrade)
Issue #2532 (static "this")
Change-Id: Id800d466e639c7cbcf4aa6fbb05114c772a2229f
The latest Closure Compiler initially complained about "initData" not
being a known property of "Event". Correcting the type to
MediaEncryptedEvent exposed a potential bug, which is that we were
assigning Uint8Array in some cases instead of the correct ArrayBuffer.
This fixes both the type of the event and converts the Uint8Arrays to
ArrayBuffers.
This also works around a complaint about "code" on "Error". We use
"Error" objects as look-alikes for DOMException because there is no
exposed constructor for DOMExceptions. To satisfy the compiler, we
use square brackets now to set the "code" field on these DOMException
look-alikes.
Finally, this removes the "method" field on certain Errors in the
WebKit EME polyfill. These must have been leftover from some
debugging, and are not used at all.
Issue #2528
Change-Id: I32c4617b14a30c412d5bc532ec17a46fdc1fea1a
These classes were over-idented, making formatting more challenging.
I wanted to fix this before making compiler-upgrade-related changes in
these files.
Issue #2528
Change-Id: Ic44448760161a3e724d8c92f41f07c1a0babfa72
These polyfills don't have the exact same type as the thing they are
polyfilling. Instead of being constructors for VTTCue (which doesn't
exist if we are using the polyfill), they are functions that return
TextTrackCue (the base class of VTTCue and the closest thing we have
on some platforms).
Because the types don't match, the latest Closure Compiler complains.
To get around this, we use square brackets.
Issue #2528
Change-Id: Ie1e3f13dc51f2145f7d3c9d510b64d9a8d7b1f64
We had made some mistakes in these prefixed names. The corrections
were made after consulting both MDN and Apple's docs.
This was caught by a compiler upgrade.
Issue #2528
Change-Id: I80994569b04a14b26b3e2fbb2673992ca7e68f50
The 'webkitkeyneeded' and 'encrypted' events send similar data, but
they were incompatible with each other and our transform handling.
This makes our polyfill produce the same format as the browser for
cases where the browser may only fire the old event. This also makes
our utilities work with the new format.
The 'webkitkeyneeded' event was a length-prefixed UTF-16 string while
the 'encrypted' event was just a UTF-8 string.
This also makes a breaking change in the transform callback to pass the
init data type. This shouldn't break anyone that only uses the first
argument; the second argument was mainly added so we could have the
default transform work without knowing anything.
This change could also break people who use custom transform functions.
The init data format is changing, which could break people who read
it directly. If they follow the tutorial and use our utilities, it
shouldn't break. This also updates the tutorial to match the new format
and be more clear about the format.
Fixes#2214
Change-Id: I006382028e828e31e20e085114fd7fd85c0e1eaa
Because we have some polyfills and blacklists that are specific to
Safari and iOS, we need to detect specific versions of Safari and iOS.
The existing detection of Safari/iOS versions was in multiple places,
and did not account for non-Safari browsers on iOS. This refactor
allows us to correctly detect iOS Chrome, and fixes a fatal exception
thrown in the MediaSource polyfill for all non-Safari browsers on iOS.
Change-Id: Ic88dc1a4c82087054cd4791dbf295b7ea2aeab09
This solution involves polyfilling the disablePictureInPicture
attribute on the video element. If the polyfill is installed, it will
show document.pictureInPictureEnabled==true, but
video.disablePictureInPicture will be a getter that does a runtime
check on that specific element using webkitSupportsPresentationMode.
disablePictureInPicture (JS property & HTML attribute) is part of the
PiP spec, so this should be sufficient to disable PiP correctly on iOS
in your application, whether or not you are using our UI.
Closes#2199
Change-Id: Iac9fc7e6cf6d4b0f7576f55af7507348ab2dc02c
This updates the fullscreen externs to:
- Add a newer definition for requestFullscreen which includes options
for the method
- Remove prefixed methods which are now built into the compiler and
are no longer necessary
- Drop document.webkitSupportsFullscreen method, which does not seem
to exist as defined, even on iOS (confusion with similar property
on video element: https://apple.co/39TLC5I)
This enables PR #2325 to resolve issue #2324
Change-Id: Ie7bea7e7d4fd59d6d801431e2ba996649e185dc1
This changes the eslint rule to enforce a strict pattern for the
argument comments. The comment must appear before the argument and
must be /* foo= */. This still ignores line comments.
Change-Id: I3afb01c65e1088eda13facb3aeeaa7595a2f5aee
This fixes several inter-related issues:
1. Catch errors in polyfill installation so that test setup isn't
interrupted half-way through
2. Use the compiled polyfill in tests, fixing polyfill installation
error during tests on IE
3. Require at least version 1.0.2 of the polyfill, since 1.0.0 had
bugs in the module export and 1.0.1 had an infinite recursion bug
Change-Id: I38c973152409d9b3168e70e82f20579566663208
The generated externs did not include shaka.polyfill because we used
the wrong annotation on the class. This fixes it.
Raised in PR #1273
Change-Id: I348064a117a7e1878b439ad8bd1ce49df56bfd39
This reflects changes in Google's policy on JavaScript license
headers, which should be smaller to avoid increasing the size of the
binary unnecessarily.
This also updates the company name from "Google, Inc" to "Google LLC".
Change-Id: I3f8b9ed3700b6351f43173d50c94d35c333e82b4
Safari 13 is out, and needs polyfills just like Safari 12 did
(although one fewer). This assumes that Safari 13+ all need the same
polyfills (to avoid surprise failures when Safari 14 comes out).
This also raises the minimum version from Safari 9 to Safari 11, since
usage stats for Safari 9 and 10 are vanishingly small. Dropping
support for Safari 9 and 10 allows us to delete a complicated polyfill
used for those versions.
Change-Id: I8f833d915215fc19a89e3aea292b67c5d677c779
These are intermittently used and cannot be verified. Most of our
methods can throw a shaka.util.Error, so having it doesn't really add
anything. Plus, if we change a function to throw, we'd need to update
all their callers to ensure they have an accurate description of what
they throw; otherwise we can't trust the directive.
Change-Id: I520bd0fc4c33443e967bf5b103ca5aa9e3274884
Using "new Uint8Array" with a TypedArray creates a copy of the buffer;
this is unnecessarily expensive for large buffers. This adds a rule
to disallow using it in favor of a new utility that correctly creates
a new "view" on the same buffer.
Note it is fine to pass an ArrayBuffer to "new Uint8Array" and it won't
copy; but there there are many cases where the type is BufferSource,
so it could be a TypedArray. Unfortunately, there are many other cases
where we explicitly pass an ArrayBuffer; but the compiler rules don't
allow us to whitelist this case (since ArrayBuffer is part of
BufferSource).
Change-Id: I58696a85a9cbcc188c0b16919c9eeb63e56edca1
This changes the network API to use BufferSource instead of ArrayBuffer,
which allows plugins to return a "view" on a buffer instead of the
whole buffer. This also adds some utilities for changing between
views and buffers.
Lastly this forbids the use of the "buffer" property of TypedArrays
since it doesn't work with partial "views". This audits and fixes the
usages of the "buffer" property to ensure correct usage.
It should be noted that both MSE and EME accept a BufferSource as input,
so we don't need to convert a "view" into an ArrayBuffer before passing
to it.
Change-Id: Iaa417773f8ce5304424e43c7372ce10ebf540d2a
Now there is a generic callback to transform the init data before
passing it to the browser. This can be used by apps to use a custom
content ID in FairPlay content. This also adds some utilities to help
in writing these functions and moves the default behavior to DrmEngine.
Closes#1951
Change-Id: I78ce660c126b53a69d5f55b16775ffcdbbe4d748
This allows a request/response filter to determine which EME session
made the request. This also changes the session ID of FairPlay sessions
so they are available too.
Issue #1951
Change-Id: I1a07abae6faf4a87fad7b5d4290a00b25e83da8e
This reverts commit 6e5a0797de, #2042.
The PR as it landed broke some test cases and functionality for storing persistent licenses, and it doesn't seem to work even for its intended use case.
* fix: Reference issue with SegmentReference createUris
* test: Added Segment GetUris Test for timeline
* feat: Get PSSH from segements if not initdata exists
* feat: Get PSSH from segements if not initdata exists
* fix: JSDoc comments and moved drmEngine update to storage
* fix: Remove comments
* fix: Remove unused import
* fix: Lint erros and dedup initData code
* fix: remove no init data test and add check for use persistent license
The Chromecast MediaSource polyfill was broken in "Avoid integer for
loops", Change-Id: I3ba3cb6a439264e823022b2a64e7cdbd265494c7.
This particular loop used to start at index 1, and the previous change
made it start at 0. Because of a test infrastructure failure that
prevented testing on Chromecast, we missed this mistake.
This bug did not affect any release versions.
This fixes the bug by using shift() to remove the first item before
the loop, instead of [0] to access it in-place.
Change-Id: I3aa53436e23a1b389375df2b06b3bbbab18ecf0b
In our tests, we can load the library many times. Each time, the
polyfills get installed, so each polyfill must be able to handle being
installed twice, and avoid any bad behavior.
The InputEvent polyfill, which is used on IE only to get correct UI
behavior on input elements, was only able to handle being installed
twice if each call was on the same copy of the library. In our tests,
this is not the case. If we load the library 20 times, we get the
polyfill installed 20 times.
Since it was comparing addEventListener with the polyfilled version,
this check would fail when the library was reloaded. Each "shaka"
namespace was distinct. So on 20 hypothetical library loads, each
polyfill would delegate to its predecessor, creating a stack some 40
functions deep. This would trigger a stack overflow when testing on
IE.
Instead, we can store the original addEventListener in some global
place, such as on HTMLInputElement.prototype.originalAddEventListener.
If that exists, the polyfill (or some version of it) was installed, so
we don't install another.
Found in Jasmine upgrade process (issue #1949)
Change-Id: I714631c9b3ac5c59cf82a5cf7501cb544d1cb5cb
Two patches in the IE EME polyfill became undefined during the ES6
conversion. These mistakes were caught by a newer compiler.
setMediaKeys was declared on a different class (MediaKeySystemAccess).
And both setMediaKeys and requestMediaKeySystemAccess needed to be
declared static in order to be referenced from a static install
method.
Issue #1852
Change-Id: Ibbeb57bb3f25e84826ab094681717fdaf1b5a8b7
This is a fully automated change. The linter will fail because the
extra indentation caused line-length errors. These won't be fixed
automatically. They are fixed in a follow-up to make this one fully
automated.
Change-Id: I4d8cf9c998985add2bcd24a81c8d65495668c4f3
With the new style rule, we cannot have two statements on the same line.
So we can no longer have an "if" on a single line and we cannot have
an arrow function with a body on the same line as when it is used.
This is mostly a manual change.
Change-Id: I2285202dd5ecbad764308bc725e6d317ff2ee7f0
Theodore Abshire
Joey Parrish
Sandra Lokshina
michellezhuo
Álvaro Velad Galván
Jacob Trimble
Germán Krauss
Joey Parrish
Ante Wall