I experimented with cross-site text track loading for the video element: http://html5videoguide.net/test/test.html In comparison, I am also loading a cross-site video for a same-site text track here: http://gingertech.net/pub/test/test.html The latter works, while the first one doesn't. Upon closer inspection it seems that the first one doesn't even try to load the remote text track. (Note: cross-site loading might be an additional problem, but until remote tracks are loaded, this can't be tested.)
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?
Thanks for the further analysis - I guess I just missed the crossorigin attribute, thinking that server setup with the HTTP headers was sufficient (Access-Control-Allow-Origin:*). I now understand that both are required to do cross-site loads. It's maybe because I have the HTTP header that the API loads it?
(In reply to comment #2) > Thanks for the further analysis - I guess I just missed the crossorigin attribute, thinking that server setup with the HTTP headers was sufficient (Access-Control-Allow-Origin:*). I now understand that both are required to do cross-site loads. It's maybe because I have the HTTP header that the API loads it? Indeed, the HTTP header is a pre-requisite for any CORS-enabled fetch, but while it's enough for video, it doesn't seem to be enough for track. (I'm not sure if this is the intention or it is a bug in the specification) What I meant to say with the API loading is that currently setting the crossorigin attribute enables both rendering and accessing the track through the API in WebKit. Intuitively, I would expect a track from a different origin to not be accessible through the API, but just rendered (for copyright purposes?). There's also a part of the spec trying to handle this aspect: "[...] It can be CORS-same-origin or CORS-cross-origin; this affects whether subtitles referenced in the media data are exposed in the API and, [...]"
I would file these two bugs, as a conclusion resulting from your example: 1) API access should be disabled for cross-origin text track resources 2) Closed Caption button shouldn't be visible if all the track resources have failed loading (e.g. in this case of a single track, but failed cross-origin request)
I've created a new bug for the second issue, see bug 106285, and re-focused this bug on the first issue. Thanks for picking this up!