Re: [whatwg] Should events be paused on detached iframes?

On Thu, Aug 26, 2010 at 12:27 AM, Boris Zbarsky 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 elemen

Re: [whatwg] base64 entities

On Thu, Aug 26, 2010 at 3:52 PM, Boris Zbarsky wrote: > On 8/26/10 6:45 PM, Adam Barth wrote: >>> >>> Note that this issue means that using atob or btoa for dealing with this >>> is >>> a huge pain if non-ASCII chars are involved, since those take and return >>> byte arrays masquerading as JS stri

Re: [whatwg] Input URL State and Files object

On 8/26/2010 7:53 PM, Jonas Sicking wrote: On Thu, Aug 26, 2010 at 5:24 PM, Charles Pritchard wrote: Chrome has gone ahead with their setData proposal, enhancing the event.dataTransfer object so that users may drag a file from within the browser onto their desktop. I would think that a same-o

Re: [whatwg] Should events be paused on detached iframes?

On 8/26/10 10:33 PM, James May wrote: Could the iframe be hoisted to the top level of its parent browsing context? Not sure what you mean. When no references remain in either the DOM or script? if an |iframe

Re: [whatwg] Input URL State and Files object

On Thu, Aug 26, 2010 at 5:24 PM, Charles Pritchard wrote: >  On 8/25/2010 2:02 PM, Ian Hickson wrote: >> >> On Mon, 2 Aug 2010, Charles Pritchard wrote: [ UAs can use  to let the user enter remote URLs ] >>> >>> When a user through selection, click+drag or manual entry of a URL >>> shoul

Re: [whatwg] Should events be paused on detached iframes?

On 27 August 2010 05:02, Boris Zbarsky 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

Re: [whatwg] Input URL State and Files object

On 8/25/2010 2:02 PM, Ian Hickson wrote: On Mon, 2 Aug 2010, Charles Pritchard wrote: [ UAs can use to let the user enter remote URLs ] 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

Re: [whatwg] base64 entities

On 8/26/10 6:45 PM, Adam Barth wrote: Note that this issue means that using atob or btoa for dealing with this is a huge pain if non-ASCII chars are involved, since those take and return byte arrays masquerading as JS strings, not actual Unicode strings. I'm slightly confused how that works. H

Re: [whatwg] base64 entities

On Wed, Aug 25, 2010 at 6:37 PM, Boris Zbarsky wrote: > On 8/25/10 7:41 PM, Adam Barth wrote: >> 2) Decoding base64 results in binary data.  We'll need to convert that >> data to characters in order to deal with it in the DOM.  We use always >> use UTF8 for that transformation, regardless of the d

Re: [whatwg] base64 entities

On 26.08.2010, at 23:28, Adam Barth wrote: >> elmt.innerHTML = 'Hi there .'; >>> >>> These cases can be secured without any new features in browsers (by >>> escaping whitespace using numeric entities): >> >> I realized I was wrong about this

Re: [whatwg] base64 entities

2010/8/26 Kornel Lesiński : > On Wed, 25 Aug 2010 22:52:42 +0100, Kornel Lesiński > wrote: >>> >>> elmt.innerHTML = 'Hi there .'; >>> >> >> These cases can be secured without any new features in browsers (by >> escaping whitespace using numeric entities): > >

Re: [whatwg] base64 entities

On 08/26/2010 10:56 PM, Aryeh Gregor wrote: I don't know of any general-purpose way to have "" in a string literal (or anywhere else), The simple approach is to use JavaScript string literal escapes: `"\x3C/script>"`. A JSON encoder may offer the option to avoid HTML-special characters in

Re: [whatwg] base64 entities

On Thu, 26 Aug 2010 22:30:00 +0200, Julian Reschke wrote: I now get the point about the additional problems in script, but I fail to see how the proposal addresses this, unless expanding these entities is suppose to happen *after* parsing the script. If you have ele.innerHTML = '&%;

Re: [whatwg] base64 entities

On Wed, 25 Aug 2010 22:52:42 +0100, Kornel Lesiński wrote: elmt.innerHTML = 'Hi there .'; These cases can be secured without any new features in browsers (by escaping whitespace using numeric entities): I realized I was wrong about this one. It won

Re: [whatwg] base64 entities

On Thu, 26 Aug 2010 21:56:12 +0100, Aryeh Gregor wrote: Suppose I have some arbitrary blob of trusted JavaScript, and I want to output it as an inline script in text/html. How do I escape it so that it executes as intended -- in particular, given that it might contain the string "" in string l

Re: [whatwg] IDL attribute reflecting enumerated attributes not limited to only know values

On Thu, Aug 26, 2010 at 2:00 PM, Ian Hickson wrote: >> * marquee.direction > > What do browsers do for this one? Seems like they don't limit it to known values, at least Firefox/Opera/Chrome. >> * meta.httpEquiv > > I'm pretty sure browsers don't treat this as limited to only known values. > >>

Re: [whatwg] Proposal for a modal element

Hi E.J., I've actually been working with some other people on the Chromium team for what we were calling a "topmost" window that could be used for modal dialogs. After some feedback, it's been suggested that we try to turn this into a more generic dialog element. I haven't yet incorporated that f

Re: [whatwg] base64 entities

On Thu, Aug 26, 2010 at 4:20 PM, Julian Reschke wrote: > I have to admit that I'm not sure what's special about here. Are > you saying that it's insufficient to escape all characters that have a > special meaning there? data:text/html,