Re: [whatwg] Full Screen API Feedback
Why can't the browser just do the fullscreen in a window behaviour until/if the user approves? No need for new events even, although a fullscreen lost, sourced eg. from some browser UI or loss of focus, might be useful. I don't see why it would make a difference from the page's perspective whether it would was actually taking up an entire screen or just all of a certain window/tab. If the user wants the fullscreen ui without actually being fullscreen, why stop them or allow pages to force them? On 12 May 2011 18:42, timeless timel...@gmail.com wrote: On Thu, May 12, 2011 at 11:12 AM, Jer Noble jer.no...@apple.com wrote: Okay, here's another proposal that should work with Firefox's passive permission system: Proposal: - Add a new boolean Element property canRequestFullScreen. This would map to Firefox's Never permission choice. - Add the fullscreendenied event. This would map to Firefox's Not now permission choice. Your proposal makes it fairly easy for sites to stick up annoying full content blocking you must change your settings to proceed elements. This is the wrong path. -- -- James May
Re: [whatwg] Html 5 video element's poster attribute
On 20 September 2010 16:17, Roger Hågensen resca...@emsai.net wrote: On 2010-09-20 05:27, Chris Pearce wrote: Right, so you want to be able to toggle the poster back on (when the media is paused or ended) but after playback has started. I wonder if these are separate use cases, e.g. whether users would want to display a different image from the poster image in these cases. i.e. I wonder if we need to provide an attribute to specify an image to display when paused and another new attribute for an image to display when playback has ended. I wonder if that's overkill through. No no no! Read my previous post why a paused poster is bad idea unless done exactly as I suggested there. A paused poster should under no circumstance steal the paused frame, the user may actually want to look closer at the pause frame, if a paused poster force itself to be displayed the user will be pretty pissed. (I certainly would be) The video streaming service Voddler is an annoying example of this, pause the movie in their player and an ad is shown, although I understand why they wish to show an ad, it does makes it impossible to pause and look at the still frame of the video. -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/ If it's done in markup it's easier to override... Forcing authors to use script for simple things like this just makes life harder for everyone.
Re: [whatwg] Should events be paused on detached iframes?
On 25 August 2010 12:50, Boris Zbarsky bzbar...@mit.edu wrote: On 8/24/10 7:09 PM, Ben Lerner wrote: The history navigation analogy is a good one: pages presumably already have to handle the pageshow event to deal with being revived from the history, and the browser already needs to know how to fire that event. Why not reuse those mechanisms? A strawman claim: Nothing may be changing from the perspective of the iframe, but it certainly is changing from the perspective of the container or the user: detaching an iframe from a page is like navigating a browsing context away from a page, putting it into hibernation until it's reattached to an active document/browsing context. What subtle or important facet of the web am I missing that breaks this analogy? (It wouldn't surprise me if I missed something obvious, either... :) At least in the case of Gecko, there are at least the following things to keep in mind: 1) hibernating documents are very limited in what one can do with them (e.g. attempting to mutate the document in any way while hibernating will throw it away). 2) Documents have security policies applied to them based on the toplevel content window (or browser tab, if you prefer to think about it) they're associated with. Which means that allowing documents not immediately associated with any toplevel window, which would be the case right now in Gecko for an iframe not in a document, leads to security problems. This could be changed by redoing how the association is implemented, but there's some touchy code involved that we'd rather not get wrong. ;) Another reason to consider suspending detached iframes: suppose that in the chat window example below, the iframe wasn't just a same-origin place to store global state, but also had its own UI, with callbacks and event handlers and whatnot. If, during the interim while the iframe was being detached, adopted and reattached, that frame executed a timer that popped up a modal alert or prompt to the user, how would the user reasonably know where that alert came from? And what document(s?) should be paused while the alert is shown? And for that matter, how would the UA know where the alert came from, in terms of correctly parenting it? This ties back to item #2 above. Couldn't the iframe be kept alive, but remain associated with it's parent browsing context until (if) it was re-parented / inserted into a different document. (does this match what other elements in the DOM behave in terms of event handlers when they are detached?) That way, complex hibernate would be uneeded and it would be clear as to how to handle events, security, etc.
Re: [whatwg] Should events be paused on detached iframes?
On 26 August 2010 17:27, Boris Zbarsky bzbar...@mit.edu wrote: On 8/26/10 3:23 AM, James May wrote: Couldn't the iframe be kept alive, but remain associated with it's parent browsing context until (if) it was re-parented / inserted into a different document. (does this match what other elements in the DOM behave in terms of event handlers when they are detached?) Elements behave fine. The question is what the Window should do. What should window.parent return in the iframe while detached? window.top? What should window.resizeTo do? That sort of thing. -Boris I thought I just suggested that? Everything works normally (as if it was still attached) until it is reattached, when the situation is re-evaluated. In terms of resource consumption, I don't see how this would be any different to any other kind of leak that web content can trigger. (I think someone mentioned that iframes can be GC'd normally)
Re: [whatwg] Should events be paused on detached iframes?
On 27 August 2010 05:02, Boris Zbarsky bzbar...@mit.edu wrote: On 8/26/10 11:58 AM, James May wrote: I thought I just suggested that? Everything works normally (as if it was still attached) until it is reattached, when the situation is re-evaluated. That could fall afoul of security checks that assume that an iframe with a non-null parent is in fact a subframe and that it's owner element is in the DOM. I know Gecko certainly has such internally. Again, nothing insurmountable, but there's a bunch of code in Gecko that makes assumptions about when windows can and can't exist that would need auditing. I can't speak to the web compat aspects. Could the iframe be hoisted to the top level of its parent browsing context? In terms of resource consumption, I don't see how this would be any different to any other kind of leak that web content can trigger. I don't think that's an issue, though this does raise the question of when it's OK to gc the iframe. When no references remain in either the DOM or script? if an iframehttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-elementis removedhttp://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#remove-an-element-from-a-documentfrom a Documenthttp://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#documentand is then subsequently garbage collected, this will likely mean (in the absence of other references) that the child browsing contexthttp://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#child-browsing-context's WindowProxyhttp://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#windowproxyobject will become eligble for garbage collection, which will then lead to that browsing contexthttp://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-contextbeing discardedhttp://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#a-browsing-context-is-discarded, which will then lead to its Documenthttp://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#documentbeing discardedhttp://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#discard-a-documentalso. This happens without notice to any scripts running in that Documenthttp://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document; for example, no unload events are fired (the unload a documenthttp://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#unload-a-document steps are not run). Although I'm not sure why this is different from the regular steps. ( http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#garbage-collection-and-browsing-contexts ) (I think someone mentioned that iframes can be GC'd normally) Can they, with your proposal? It seems that with your proposal if you remove an iframe from the DOM and then forget about it then as long as there's any network activity in that iframe or anything else which might potentially trigger script it cannot be gced. This seems like it would make it very easy to leak document after document... So running scripts and network activity are GC roots? -- James
Re: [whatwg] HTML resource packages
On 4 August 2010 20:08, Christoph Päper christoph.pae...@crissov.de wrote: * Argument: What about incremental rendering? If there are, for instance, lots of (content) images in the resource file I will see them all at once as soon as the ZIP has been downloaded completely and decompressed, but with single files I would have seen them appear one after the other, which might have been enough. ZIP files are progressively renderable, dependant on file order.
Re: [whatwg] Input URL State and Files object
Why wouldn'tinput type=file be usable for this? You should be able to drag any file to that, just like you can type in a URL in Windows in an open file dialog box. input type=file would be usable. Were this implemented: When a user through selection, click+drag or manual entry of a URL should the browser still submit an Origin request header? It seems that CORS doesn't come into effect here -- but at the same time, it'd be handy for logging purposes and added security. When a cross-site resource is fetched via CORS, the agent submits an Origin header. A secure site (such as a bank), may always return a Forbidden response if the Origin header is set; blocking any kind of cross-site sharing, even sharing attempted by a user (through an input type=file field). On Windows at least, when put a URL in the open dialog the shell downloads it then passes a temporary file. The browser never gets the source URL - so it'd be difficult without re-implementing the dialog (undesirable). Plus user control, and all that. -- James
Re: [whatwg] Content-Disposition property for a tags
Perhaps to avoid the legacy baggage it could be a simple attribute eg. a href=blah download This would prevent duplicating 'type', and bringing in all the knowledge people seem to not have about how 'content-disposition' works in headers. or even an extension of target? eg. a href=blah target=_save Then it would be clear that it's only a hint, like the other target values. -- James (I accidentally sent this to the wrong address before sorry for the dupe) On 3 August 2010 03:37, Boris Zbarsky bzbar...@mit.edu wrote: On 8/2/10 1:15 PM, Aryeh Gregor wrote: If you don't agree that this use-case is worth adding the feature for, do you think that: 3) Something else? For the use case your describe, it might just make more sense for browsers to support Content-Disposition on data: URIs directly somehow... Maybe. -Boris
Re: [whatwg] WebSockets: UDP
Couldn't SCTP/DCCP (or a variant) over UDP (for NAT compatibility) work? They seem both seem to be session oriented while loosening the other restrictions of TCP, On 4 June 2010 00:18, Philip Taylor excors+wha...@gmail.comexcors%2bwha...@gmail.com wrote: On Thu, Jun 3, 2010 at 7:28 AM, Erik Möller emol...@opera.com wrote: [...] One thing to remember here is that browsers have other means for communication as well. I'm not saying we shouldn't support reliable messages over UDP, but just pointing out the option. Yep - the relevant use cases ought to be supported decently by the platform, but not necessarily by this extension to the platform (it might be a different extension or it might be (probably is) supported already). - Protection against an attacker initiating a legitimate socket with a user and then redirecting it (with some kind of IP (un)hijacking) to a service behind the user's firewall (which isn't a problem when using TCP since the service will ignore packets when it hasn't done the TCP handshake; but UDP services might respond to a single packet from the middle of a websocket stream, so every single packet will have to be careful not to be misinterpreted dangerously by unsuspecting services). I don't quite follow what you mean here. Can you expand on this with an example? I was thinking something like: A host at IP 11.11.11.11 on the public internet runs some UDP service, like DNS or TFTP or something a bit more secure. That service is restricted so it only responds to packets received from IP 22.22.22.22 (a trusted user). The UDP Web Socket handshake is carefully constructed so that it won't trigger dangerous behaviour in any of those services (like how the TCP Web Socket uses a safe HTTP-ish handshake). An attacker hijacks the IP 11.11.11.11 from the perspective of the user (by advertising new routes near the user), so the user's packets to that address go to the attacker. The attacker gets the user to visit a web page which sets up a UDP Web Socket with the attacker's server at 11.11.11.11, doing all the handshake authentication correctly. The attacker then releases its hijacked address, so any subsequent Web Socket packets will go to the original restricted service. Since they're being received from the trusted user, the service will trust them. Since the web browser has already done the Socket handshake, it will believe it's talking to a legitimate Web Socket server and will continue sending whatever data packets the attacker's script tells it to. The service will then be receiving and responding to attacker-controlled packets, and will never have seen the carefully constructed handshake that's designed to protect it. That's not a danger for TCP services since they'll reject unexpected packets from the middle of a TCP stream, but UDP services may accept packets from the middle of a UDP Web Socket stream. So it's not sufficient to carefully construct the Web Socket handshake packets to not trigger unwanted behaviour in non-Socket services. Every data packet sent on the Socket has to be carefully constructed too. (This might be a largely impractical or pointless attack, and there's probably much easier ways to attack the exposed service, but I don't know enough about security to judge that. Also I don't know what packet construction would be sufficiently careful. But it seems like a possible new concern that's introduced when using UDP in this context.) -- Philip Taylor exc...@gmail.com
Re: [whatwg] Inconsistent behavior for empty-string URLs
If this change is made, what is the correct (explicit) way to refer to the current URL? . ? In terms of web compat, I do recall a web picture gallery package that returned a html information page with a self reference to show the actual image. -- James 2009/12/15 Maciej Stachowiak m...@apple.com On Dec 14, 2009, at 11:08 AM, Nicholas Zakas wrote: It seems that thusfar, Jonas from Mozilla is open to this change. Is there anyone from Opera or WebKit that would like to chime in either in favor or opposition? I'd love to issue fewer useless loads, if sites don't actually rely on it. Does anyone have data on what, if any, compatibility impact this has? I can't imagine loading the base URL to be terribly useful in most cases, but perhaps there are wacky sites that do indeed rely on it. Regards, Maciej Thanks. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas Sent: Friday, December 11, 2009 10:15 AM To: Simon Pieters; Anne van Kesteren; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs I agree, automatic downloads are the real issue. a href= is fine because a user must initiate the action (and thus generate a real pageview). I'd think that the behavior should be the same in CSS and SVG for resources that are automatically downloaded. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Thursday, December 10, 2009 10:57 AM To: Nicholas Zakas; Anne van Kesteren; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: I'd be happy to make the compromise that this applies to markup but not to JavaScript APIs. I think it shouldn't apply to markup that doesn't download things automatically; in particular a href= should work. What about URLs in CSS and SVG? -- Simon Pieters Opera Software
