[whatwg] Firing canplaythrough when caches/buffers are full

[Robert O'Callahan]

We encountered an app that uses "canplaythrough" on a video element to
trigger execution of the app "so we don't start playing the video until we
can do so without stuttering".
http://gaiamobile.org/apps/cubevid/
This approach works fine on desktop browsers. On mobile browsers, we want a
smaller limit on the amount of data buffered by the media subsystem. That
means we pause the download before "canplaythrough" would fire, so it never
fires, so the app doesn't work.

We could fix this particular app, but this seems like a natural thing for
authors to do and get wrong.

I propose fixing this by having the UA enter the HAVE_ENOUGH_DATA
readyState when the UA decides to suspend a download indefinitely and the
preload state is "Automatic" (or overriden by "autoplay" being set).

We have checked in a patch to Gecko to do this. (Note that for a long time,
Gecko has triggered playback of autoplay elements when suspending due to
media buffers being full. The new change makes us enter HAVE_ENOUGH_DATA as
well.)

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]

Re: [whatwg] AllowSeamless

[Markus Ernst]

Am 27.05.2012 12:19 schrieb Adam Barth:

On Sun, May 27, 2012 at 3:00 AM, Markus Ernst  wrote:

Am 27.05.2012 02:16 schrieb Adam Barth:

I've added a proposal to the wiki
about letting a document
indicate that it is willing to be displayed seamlessly with a
cross-origin parent.  This proposal is a refinement of the approach
previously discussed in this thread:
.

Let me know if you have any feedback.


I have a strong feeling that per-origin control should be made easy for
authors. I must admit that I am not familiar with the mechanisms you name,
Frame-Options and ancestor-origins - and both are quite hard to google for.
 From what I found I assume both are about HTTP headers.

If they are solutions that can be used easily with server-side languages
such as PHP, I think we can live with it. But anyway it is a complication;
I'd personnally prefer something like
allowseemles="example.org, *.example.org, shop.otherdomain.com"

Or maybe space separated, and separate inherit-style with comma:
allowseemles="example.org *.example.org shop.otherdomain.com, inherit-style"

(Regardless of whether it is in the HTML element or in a META element.)


I had difficulty coming up with use cases that weren't better served
with frame-ancestors and/or Frame-Options.  Do you have a specific use
case in mind to explain your feelings?


My use case is a content provider, who provides e.g. a Sudoku 
application or a weather forecast for wind surfers. Paying customers are 
allowed to embed the content seamlessly in their web sites. The content 
can also be embedded for free, but not seamlessly.


The content provider includes some corporate info, such as his/her own 
logo, and a "provided by XY" notice and link to his/her own page. The 
paying customers then can apply their own styling, and set the corporate 
info to "display:none" in the style sheet of the top document, via 
seamless embedding.

Re: [whatwg] AllowSeamless

[Adam Barth]

On Sun, May 27, 2012 at 3:00 AM, Markus Ernst  wrote:
> Am 27.05.2012 02:16 schrieb Adam Barth:
>> I've added a proposal to the wiki
>>   about letting a document
>> indicate that it is willing to be displayed seamlessly with a
>> cross-origin parent.  This proposal is a refinement of the approach
>> previously discussed in this thread:
>> .
>>
>> Let me know if you have any feedback.
>
> I have a strong feeling that per-origin control should be made easy for
> authors. I must admit that I am not familiar with the mechanisms you name,
> Frame-Options and ancestor-origins - and both are quite hard to google for.
> From what I found I assume both are about HTTP headers.
>
> If they are solutions that can be used easily with server-side languages
> such as PHP, I think we can live with it. But anyway it is a complication;
> I'd personnally prefer something like
> allowseemles="example.org, *.example.org, shop.otherdomain.com"
>
> Or maybe space separated, and separate inherit-style with comma:
> allowseemles="example.org *.example.org shop.otherdomain.com, inherit-style"
>
> (Regardless of whether it is in the HTML element or in a META element.)

I had difficulty coming up with use cases that weren't better served
with frame-ancestors and/or Frame-Options.  Do you have a specific use
case in mind to explain your feelings?

Adam

Re: [whatwg] AllowSeamless

[Markus Ernst]

Am 27.05.2012 12:00 schrieb Markus Ernst:

allowseemles="example.org *.example.org shop.otherdomain.com,
inherit-style"


It seams I made a typo here.

Re: [whatwg] AllowSeamless

[Markus Ernst]

Am 27.05.2012 02:16 schrieb Adam Barth:

Hi whatwg,

I've added a proposal to the wiki
  about letting a document
indicate that it is willing to be displayed seamlessly with a
cross-origin parent.  This proposal is a refinement of the approach
previously discussed in this thread:
.

Let me know if you have any feedback.


I have a strong feeling that per-origin control should be made easy for 
authors. I must admit that I am not familiar with the mechanisms you 
name, Frame-Options and ancestor-origins - and both are quite hard to 
google for. From what I found I assume both are about HTTP headers.


If they are solutions that can be used easily with server-side languages 
such as PHP, I think we can live with it. But anyway it is a 
complication; I'd personnally prefer something like

allowseemles="example.org, *.example.org, shop.otherdomain.com"

Or maybe space separated, and separate inherit-style with comma:
allowseemles="example.org *.example.org shop.otherdomain.com, inherit-style"

(Regardless of whether it is in the HTML element or in a META element.)

--
Markus

Re: [whatwg] AllowSeamless

[Adam Barth]

On Sat, May 26, 2012 at 10:13 PM, Maciej Stachowiak  wrote:
> On May 26, 2012, at 5:16 PM, Adam Barth  wrote:
>> I've added a proposal to the wiki
>>  about letting a document
>> indicate that it is willing to be displayed seamlessly with a
>> cross-origin parent.  This proposal is a refinement of the approach
>> previously discussed in this thread:
>> .
>>
>> Let me know if you have any feedback.
>
> Hi Adam,
>
> Seems like your use case is well motivated. Two points of feedback:
>
> 1) In the Alternatives section, you didn't talk about the alternative of a 
> newly created HTTP header, or else extending one of the headers already 
> affecting embedding security, or in general the tradeoffs of header vs. 
> signifier inside the HTML document to be embedded. I don't have a particular 
> pre-existing opinion on this, but it seems like at least some of the 
> precedent in this case is based on HTTP headers, and it would be good to 
> understand the tradeoffs.

I included some discussion of the Content-Security-Policy header.  Is
there another HTTP header that you think would be appropriate to
extend with this information?  I guess there's a case to be made for
including it in Frame-Options.  I've sort of been hoping we can merge
Frame-Options back into Content-Security-Policy, but that challenge is
more social than technical.

> 2) It seems like, even if it might not be appropriate to require CORS for 
> this use case, it seems like allowing CORS access should at least be 
> sufficient even if not necessary. In other words, if you are prepared to use 
> CORS anyway for other reasons, then it seems like that should also allow 
> seamless embedding. But perhaps this makes the model too complicated.

In order for the CORS check to pass, we'd need to introduce a
crossorigin attribute for iframes (like we've done for images and
scripts).  We might end up doing that anyway, and if/when we do, maybe
it would be appropriate to have that allow seamless.  However, there's
still problem (2) from the wiki regarding leaking information about
subresources.

Adam