Re: [whatwg] Proposal: Two changes to iframe@sandbox
On Thu, Jul 9, 2015 at 5:28 PM, Daniel Veditz dved...@mozilla.com wrote: On Mon, Jul 6, 2015 at 2:47 AM, Mike West mk...@google.com wrote: I've dropped the opener/openee-disowning behavior from my proposal, and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvmentsdiff=9958oldid=9955 It appears that this new keyword as described would still require the use of allow-popups in addition to allow-popups-to-escape-sandbox. Since it doesn't make any sense on its own can you change it so that either keyword allows popups to happen? That it, propose changing [Set] The sandboxed auxiliary navigation browsing context flag https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag, unless tokens contains the allow-popups keyword. to [Set] The sandboxed auxiliary navigation browsing context flag https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag, unless tokens contains the allow-popups or *allow-popups-to-escape-sandbox* keyword. (might then require changing -to-escape- to -that-escape-) My only concern with this is that folks might disallow certain sanboxing flags that they know are dangerous, which might mean that their CMS would block `allow-plugins`, but might allow new flags (which would then allow someone to `allow-plugins-to-escape-sandbox`. This kind of blacklisting is probably a bit far fetched, so I could live with the behavior if you feel strongly about it, but I'd prefer to keep the changes as small and additive as possible. -mike
Re: [whatwg] preload=metadata elements don't necessarily fire canplay
On Tue, Jul 14, 2015 at 10:33 PM, Philip Jägenstedt phil...@opera.com wrote: I see, is this a policy that's applied even with a single video in a page, or is it something like a limit on the total number of players that can be created, or limits on how much stuff (decoders) they set up internally? Presto actually had a limit on the number of players on 32-bit systems, as one might otherwise run out of virtual memory with just a few hundred video elements... There are various kinds of resource limits. The problem with those is that they're fragile and make behavior unpredictable. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
Re: [whatwg] preload=metadata elements don't necessarily fire canplay
On Tue, Jul 7, 2015 at 11:56 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 7, 2015 at 9:41 PM, Philip Jägenstedt phil...@opera.com wrote: Unsurprisingly, I like this, as it's basically what Presto did. However, I think preload=metadata should reach HAVE_CURRENT_DATA, because you do want to decode the first frame. The naming mismatch is weird, but oh well. OK. The question is, would Chrome(ium) be willing to implement that reasonably quickly? I'm not optimistic given the canplaythrough debacle... Do you have links to previous debacles, so that I can see what the constraints are, or have been? The constraint just seems to be a lack of interest in fixing interop issues in this area: http://code.google.com/p/chromium/issues/detail?id=73609 Thanks for the link. It looks like some attempt was made to fix it on the Chromium side (i.e. in the media framework, not HTMLMediaElement) and that the effort was abandoned. A simple clamping of readyState in HTMLMediaElement would presumably be quite simple to implement, and would reveal if it's web compatible or not quite quickly. Hixie, do you have the bandwidth to figure out a spec for this at this point? If not, maybe roc and I could work it out in a spec bug and you can review? Philip
Re: [whatwg] preload=metadata elements don't necessarily fire canplay
On Tue, Jul 14, 2015 at 3:15 AM, Robert O'Callahan rob...@ocallahan.org wrote: Apart from the problems already discussed here, there is currently no specced or interoperably implemented way to set a preload value that guarantees HAVE_CURRENT_DATA, HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA will be reached ... auto may do one of those things, but it doesn't have to, and in fact on mobile Firefox we don't guarantee any of those things. So I suggest we revamp preload as follows: preload=none: the goal readyState is HAVE_NOTHING. preload=loadedmetadata: the goal readyState is HAVE_METADATA. preload=metadata: the goal readyState is HAVE_METADATA (or some higher value if needed for Web compatbility). preload=loadeddata: the goal readyState is HAVE_CURRENT_DATA. preload=canplay: the goal readyState is HAVE_FUTURE_DATA. preload=canplaythrough: the goal readyState is HAVE_ENOUGH_DATA. (Thus the expectation for authors is that if you set preload=X then event X will eventually fire.) I would spec that while the autoplaying flag is true, the readyState of the element is limited to less than or equal to the goal readyState if there is one. (Note that the autoplaying flag value does not depend on the presence of the autoplay attribute.) Would it solve the same practical problems if auto were redefined to mean that the goal readyState is HAVE_ENOUGH_DATA? Is there a reason it doesn't do this in mobile Firefox? Philip
Re: [whatwg] preload=metadata elements don't necessarily fire canplay
On Tue, Jul 14, 2015 at 8:51 PM, Philip Jägenstedt phil...@opera.com wrote: Would it solve the same practical problems if auto were redefined to mean that the goal readyState is HAVE_ENOUGH_DATA? Probably. Is there a reason it doesn't do this in mobile Firefox? We don't want a page with many video preload elements to collapse. Maybe we shouldn't worry about that. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
Re: [whatwg] preload=metadata elements don't necessarily fire canplay
On Tue, Jul 14, 2015 at 1:08 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 14, 2015 at 10:33 PM, Philip Jägenstedt phil...@opera.com wrote: I see, is this a policy that's applied even with a single video in a page, or is it something like a limit on the total number of players that can be created, or limits on how much stuff (decoders) they set up internally? Presto actually had a limit on the number of players on 32-bit systems, as one might otherwise run out of virtual memory with just a few hundred video elements... There are various kinds of resource limits. The problem with those is that they're fragile and make behavior unpredictable. Yeah, this is tricky, obviously no browser could successfully load a million video elements up to readyState HAVE_ENOUGH_DATA simultaneously, but making that fail in the same way cross-browser seems like a big task. If the behavior could be made interoperable for when resources are not a problem, that would be a good start at least. The spec can say that the browser should at least try to ready HAVE_ENOUGH_DATA for preload=auto, to rule out artificial limits if any browser has them. Philip
Re: [whatwg] preload=metadata elements don't necessarily fire canplay
On Tue, Jul 14, 2015 at 11:57 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 14, 2015 at 8:51 PM, Philip Jägenstedt phil...@opera.com wrote: Would it solve the same practical problems if auto were redefined to mean that the goal readyState is HAVE_ENOUGH_DATA? Probably. Is there a reason it doesn't do this in mobile Firefox? We don't want a page with many video preload elements to collapse. Maybe we shouldn't worry about that. I see, is this a policy that's applied even with a single video in a page, or is it something like a limit on the total number of players that can be created, or limits on how much stuff (decoders) they set up internally? Presto actually had a limit on the number of players on 32-bit systems, as one might otherwise run out of virtual memory with just a few hundred video elements... Philip
Re: [whatwg] preload=metadata elements don't necessarily fire canplay
On Tue, Jul 14, 2015 at 1:17 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 14, 2015 at 11:13 PM, Philip Jägenstedt phil...@opera.com wrote: If the behavior could be made interoperable for when resources are not a problem, that would be a good start at least. The spec can say that the browser should at least try to ready HAVE_ENOUGH_DATA for preload=auto, to rule out artificial limits if any browser has them. If that behavior is required for Web compatibility, then we should do it. However I also think there's value in having a preload value that preloads aggressively on some platforms but not on others. Basically a I trust the browser to decide and promise not to assume anything state? The auto state is already suitable named and defined for that, so if implementing auto as anything other than try to reach HAVE_ENOUGH_DATA is in fact web compatible, a new state for that might make sense. Practically speaking, though, what would be the policy for auto that differs between platforms, in the case of a single video element in a page? If the different policies could be made explicit, it might be nice to have explicit preload states for them and a way for scripts to know the effective preload state. Philip
Re: [whatwg] preload=metadata elements don't necessarily fire canplay
On Tue, Jul 14, 2015 at 11:13 PM, Philip Jägenstedt phil...@opera.com wrote: If the behavior could be made interoperable for when resources are not a problem, that would be a good start at least. The spec can say that the browser should at least try to ready HAVE_ENOUGH_DATA for preload=auto, to rule out artificial limits if any browser has them. If that behavior is required for Web compatibility, then we should do it. However I also think there's value in having a preload value that preloads aggressively on some platforms but not on others. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
Re: [whatwg] preload=metadata elements don't necessarily fire canplay
On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt phil...@opera.com wrote: Basically a I trust the browser to decide and promise not to assume anything state? The auto state is already suitable named and defined for that, so if implementing auto as anything other than try to reach HAVE_ENOUGH_DATA is in fact web compatible, a new state for that might make sense. Practically speaking, though, what would be the policy for auto that differs between platforms, in the case of a single video element in a page? Our current policy, which is basically HAVE_ENOUGH_DATA on desktop and HAVE_METADATA on mobile. If the different policies could be made explicit, it might be nice to have explicit preload states for them and a way for scripts to know the effective preload state. Maybe that's overengineering. I propose we leave 'auto' as-is for now until we have more data, and first do the other work I mentioned. Then a possible next step would be to determine how much preloading preload=auto must do for Web compatibility (i.e., which readyState it must reach), and define preload=auto to have that as the goal readyState, *but* we could also say that it preloads as much data as possible given browser-specific policy (while not actually advancing the readyState beyond the goal readyState until the autoplaying flag is false). Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
