[Webkit-unassigned] [Bug 103110] [Track] Video Text Tracks from cross-site are not loaded

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Jan 6 13:27:29 PST 2013


Victor Carbune <victor at rosedu.org> changed:

           What    |Removed                     |Added
                 CC|                            |victor at rosedu.org

--- Comment #1 from Victor Carbune <victor at rosedu.org>  2013-01-06 13:29:26 PST ---
I'm trying to understand properly the specification.
Both cases are 'potentially CORS-enabled' fetch of media resources.

(In reply to comment #0)
> I experimented with cross-site text track loading for the video element:
> http://html5videoguide.net/test/test.html
In this case, according to the specification:
"[...] let CORS mode be the state of the parent media element's crossorigin
content attribute. Otherwise, let CORS mode be No CORS."

> In comparison, I am also loading a cross-site video for a same-site text track here:
> http://gingertech.net/pub/test/test.html
This seems to be treated differently:
"Perform a potentially CORS-enabled fetch [...], with the mode being the state of
the media element's crossorigin content attribute [...] and the default origin
behaviour set to taint."

Since in both cases there is no value for the "crossorigin" attribute, both end
up with the "No CORS" situation, but with the default origin behaviour different
(for video explicitly set to 'taint', for track implicitly set to 'fail'?).

Reading the CORS-enabled fetch algorithms, it seems that for 'taint' it won't
fail, while for 'fail' it will (I get a message on the debugging console)

It's also worth noting that if I set the crossorigin="anonymous" in the first
case, the text track does get loaded and I can access its contents through the
API as well (this might be a bug? I think if it's cross-origin it should not be
accessible through the API).

Is there something I'm mis-reading from the spec?

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list