Re: [whatwg] sandboxed documents and cookies

[Ian Hickson]

On Fri, 15 Jun 2012, Ian Melven wrote:
> 
> in https://bugzilla.mozilla.org/show_bug.cgi?id=341604#c180, David-Sarah 
> Hopwood makes a few points about cookies in sandboxed documents :
> 
> "Ugh, that's mandating an information leak about whether the document 
> has cookies. Maybe a minor leak, but I don't understand why it should 
> exist: if allow-same-origin is not set, then the clear intent is that no 
> information about cookies should be available."
> 
> "Oh, and another reason not to do it that way is that it's a testing 
> hazard for web developers. They test when there are no cookies, it 
> works, then the parent document adds cookies (which has no reason to 
> make any difference), and it breaks because the code in the sandboxed 
> document didn't expect the exception."
> 
> The spec (http://dev.w3.org/html5/spec/dom.html#sandboxCookies) says : 
> "On getting, if the document is a cookie-free Document object, then the 
> user agent must return the empty string. Otherwise, if the Document's 
> origin is not a scheme/host/port tuple, the user agent must throw a 
> SecurityError exception."
> 
> IE 10, Chrome and the patches I am working on for Firefox all throw a 
> SecurityError even if no cookies are set - i agree that this seems like 
> the correct behaviour.

I believe you have a mistaken understanding of what "cookie-free Document" 
meant. I've renamed the term to avoid the confusing interpretation. It's 
now called a "cookie-averse Document". Please let me know if you still 
think the logic described in the specification is incorrect.

Thanks,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] iframe sandbox attribute

[Boris Zbarsky]

On 7/9/12 8:39 PM, Ian Hickson wrote:

Surely that's going to set the attribute regardless of whether the
attribute is nullable or whatnot.


Well, that depends on how reflecting "DOMString?" attributes are 
defined.  Making setting null call removeAttribute would work much like 
boolean attributes work.



I mean, this always sets the attribute
even if the attribute wasn't previously set:

myElement.title = myElement.title


Yes, but myElement.checked = myElement.checked does not.


More importantly,

   myOtherFrame.sandbox = myFrame.sandbox;

doesn't have weird surprising behavior if the attribute is something
whose value sanely distinguishes between the various possible sandbox
values.


I'm not sure I follow.


The point is that 'not set' and 'empty string' don't mean the same thing 
for @sandbox, and ideally the DOM reflection would preserve the distinction.



I think remaining consistent with other non-boolean attributes, and thus
having the setter always set the attribute, is fine.


And I think it's a footgun.

-Boris

Re: [whatwg] Additional attribute value for iframe sandbox

[Ian Hickson]

On Mon, 30 Apr 2012, Tim Streater wrote:
>
> I'd like to request that it be possible for links in sandboxed iframes, 
> when clicked, to open in a new window. My reading of the documentation 
> suggests that in a sandboxed iframe, links are disabled except that 
> "allow-top-navigation" permits the equivalent of "target='_top'". In 
> effect, I'd like a new value that permits "target='_blank'". Testing 
> today tells me that in fact in Safari 5.1.5 at least, a sandboxed iframe 
> does not interfere in any way with links.
> 
> My use case is this. My application, a mail client, receives html emails 
> and uses an iframe to display them. A good example of such a mail can be 
> seen here:
> 
> http://www.newscientist.com/data/projects/newsletter/newsletter20120430rwau.html
> 
> (When I receive it, the recipient's email address is in the bottom part 
> of the page rather than #emailaddr#.) This is an example of a trusted 
> email which has links. At present, my application strips out scripts as 
> a primitive security measure, but I'd rather use a sandboxed iframe if 
> possible. However, a user will expect to be able to click on a link in 
> such an email and have a new window opened, separate from the email 
> client. Hence my request for a new value for the sandbox attribute.

On Mon, 30 Apr 2012, Charles Pritchard wrote:
> On 4/30/12 2:04 PM, Tim Streater wrote:
> > On 30 Apr 2012 at 21:17, Charles Pritchard  wrote:
> > > They've got an allow-popup in IE and I think WebKit. It's just a 
> > > little slow going in getting it firmly out there.
> >
> > Yes, I saw that as I worked on through the archive. But they want to 
> > enforce the same restrictions on the newly-opened window as the iframe 
> > had. I'd prefer no restrictions, but also no connection back from the 
> > opened window to its parent. IOW, just as if one had opened a new 
> > browser window and typed the URI in manually.
> 
> The about:blank +  hack is no fun; the thing used to break 
> out of origin in webkit.
> 
> I'd hoped iframe sandbox had that solved.

Well, nothing stops the user from opening any links the user wants to open 
wherever the user wants to open them. All sandbox="" does is prevent the 
page from automatically opening pages.

I'm not 100% clear on what you're trying to block with sandbox if that's 
not sufficient. Maybe if you could describe your threat model in more 
detail it would be clearer?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] iframe sandbox attribute

[Ian Hickson]

On Mon, 26 Mar 2012, Boris Zbarsky wrote:
> On 3/26/12 3:19 PM, Ian Hickson wrote:
> > Changing it to a string doesn't affect that, though, does it?
> 
> Well, changing to a nullable string does affect it because doing 
> something like this:
> 
>   myFrame.sandbox = myFrame.sandbox;
> 
> is a no-op, as by all sane rights it should be

Surely that's going to set the attribute regardless of whether the 
attribute is nullable or whatnot. I mean, this always sets the attribute 
even if the attribute wasn't previously set:

   myElement.title = myElement.title


> More importantly,
> 
>   myOtherFrame.sandbox = myFrame.sandbox;
> 
> doesn't have weird surprising behavior if the attribute is something 
> whose value sanely distinguishes between the various possible sandbox 
> values.

I'm not sure I follow.


> > We can certainly add an attribute to DOMSettableTokenList (or rather, 
> > a descendant, for use specifically with iframe.sandbox) that does the 
> > same as .hasAttribute(), e.g.:
> > 
> > iframe.sandbox.present
> > 
> > ...or something, if that would help.
> 
> Would we also make the attribute readonly, then, and require that it be 
> set via the token list?  Otherwise, it seems like the snippets above 
> would still have pretty unexpected behavior.  But even then they might, 
> since sets of readonly props are just silently ignored.  :(

I think remaining consistent with other non-boolean attributes, and thus 
having the setter always set the attribute, is fine.


On Thu, 29 Mar 2012, Adam Barth wrote:
>
> I guess I don't see much value in using DOMSettableTokenList for the 
> sandbox property.  I don't expect folks to mutate the property much. 
> They're just likely to set it to a constant and be done with it.  The 
> situation is very different for a property like className, where there's 
> a strong use case for mutating.

On Fri, 30 Mar 2012, Ian Melven wrote:
> 
> I agree that it's pretty likely folks won't be mutating this property 
> very often - the HTML5 spec actually recommends against messing with the 
> sandbox attribute dynamically at all:
> 
> "Generally speaking, dynamically removing or changing the sandbox 
> attribute is ill-advised, because it can make it quite hard to reason 
> about what will be allowed and what will not."

On Fri, 30 Mar 2012, Adam Barth wrote:
> 
> IMHO, it's better if the sandbox property behaves like other properties 
> rather than being magically different.  In these cases, the result is 
> more sandboxing than you might expect rather than less, which is 
> probably fine.

On Fri, 30 Mar 2012, Jonas Sicking wrote:
> 
> I think there's a lot of logic to that. One thing that I think we should 
> do as part of that is to drop the DOMSettableTokenList. By far more 
> "mapped attributes" are normal DOMStrings.

On Sat, 31 Mar 2012, Anne van Kesteren wrote:
> 
> Such as? I thought the whole point was to do away with that so that 
> authors do not have to implement the parsing logic anymore.

Upon reflection, I haven't changed anything here. I don't see much value 
in making an exception to 'sandbox' here.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Interaction between and CSS image-resolution

[Tab Atkins Jr.]

On Mon, Jun 4, 2012 at 1:25 AM, Simon Pieters  wrote:
> How do  and CSS image-resolution interact? What happens with
> e.g. ?

I think that the @srcset resolution should be treated as an intrinsic
resolution.  In your example, then, 'image-resolution' would override
the 2x (though both specify the same value, obviously).  Using
"from-image", though, would defer to the @srcset resolution.

~TJ

[whatwg] seamless iframes and event propagation

[Ojan Vafai]

I'd like to see us add event propagation into the parent document for
seamless iframes, e.g. key and mouse events inside a seamless iframe should
be refired on the iframe element.

Use-case 1: A global key event handler for keyboard shortcuts. Without
propagating the events, you need to add a key handler to each seamless
iframe's root in order for these keyboard handlers to work when the iframe
has focus.

Use-case 2: A dragging UI. Without event propagation, if you don't add
handlers to the iframe's root, you would just stop dragging when the mouse
is over seamless iframes. In addition, the coordinates of the mouse event
should be changed to the parent document's coordinate space when it is
refired on the iframe, otherwise your code needs to know when it's over an
iframe.

We should fire two events. One inside the iframe and one on the iframe
element itself (in the parent document). Any pointers to DOM nodes in the
event would need to be nulled out in the event fired in the parent document
if the seamless iframe is cross-domain and non-CORS accessible.

This makes seamless iframes more seamless. Most existing keyboard shortcut
and dragging JS code would magically keep working without needing to know
anything about seamless.

Use-case 3: Making an email client that wants the content of the email
isolated from the client's UI, but doesn't want a nested scrollbar (i.e.
the editable area sizes to the emails size). In this case, you don't want
to inherit the CSS for the mail client into the email's content. Similarly,
you may not want your global keyboard handlers to run when typing in the
editable area.

Similar to Adam's allow-seamless proposal, I'd like to see seamless have
the ability to tweak which bits of the frame act seamlessly. Adam's
proposal has inherit-styles. We could also add propagates-events to
allow-seamless. Both of those would be off by default. For seamless, we
could have no-inherit-styles and no-propagate-events in order to disable
either behavior, also off by default.

Ojan

On Sat, May 26, 2012 at 5:16 PM, Adam Barth  wrote:

> 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.
>
> Thanks!
> Adam
>

Re: [whatwg] Sublties with seamless navigation

[Ian Hickson]

On Tue, 10 Apr 2012, Adam Barth wrote:
>
> Consider the following requirement for seamless iframes:
> 
> http://www.whatwg.org/specs/web-apps/current-work/#seamlessLinks
> 
> [[
> If the source browsing context is the same as the browsing context
> being navigated, and this browsing context has its seamless browsing
> context flag set, and the browsing context being navigated was not
> chosen using an explicit self-navigation override, then find the
> nearest ancestor browsing context that does not have its seamless
> browsing context flag set, and continue these steps as if that
> browsing context was the one that was going to be navigated instead.
> ]]
> 
> However, that requirement seems to be a bit too agressive.  For example, 
> setting the "src" attribute on the iframe element loads the document in 
> the iframe using the Navigate keyword.

Uh, yeah. Oops. Fixed.


> Should we be more explicit in 
>  
> about what the source browsing context is?

The more relevant part is:

   
http://www.whatwg.org/specs/web-apps/current-work/#process-the-iframe-attributes

It seems pretty explicit, I don't know how to make it more so. :-)

I fixed it by making the navigation in that algorithm always an explicit 
self-navigation override.


> Is it always the browsing context that contains the  element, or 
> does it depend on which script is manipulating the src attribute (e.g., 
> via the DOM)?

Always the iframe's nested browsing context.


> Should setting the src attribute use an explicit self-navigation 
> override?

Yes.


> The easiest solution is probably to specify the source browsing context 
> explicitly, as we do for window.open 
>  and 
> location.href 
> .

It's already set explicitly, but it's set to its own nested browsing 
context, which is where the problem starts.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] seamless iframes

[Ian Hickson]

On Wed, 4 Apr 2012, Ojan Vafai wrote:
>
> 1.  We should add iframe[seamless] { display:block; }. 
> http://www.whatwg.org/specs/web-apps/current-work/#embedded-content-2 
> already expects iframe:not([seamless]) { border: 2px inset; }. In 90% 
> percent of uses, seamless iframes will not want a border and will want 
> to fill their container. This way, seamless iframes behave roughly like 
> sandboxable divs, which is what web developers want.

Done.


> 2. 
> http://www.whatwg.org/specs/web-apps/current-work/#attr-iframe-seamless 
> "In visual media, in a CSS-supporting user agent: the user agent should 
> set the intrinsic width of the iframe to the width that the element 
> would have if it was a non-replaced block-level element with 'width: 
> auto'."
>
> This doesn't get the behavior you'd want with cases that need
> shrink-wrapped behavior. Some cases that need handling:
> 
> 
> 
> 

Done.


On Wed, 4 Apr 2012, Ojan Vafai wrote:
> 
> 3. The default margin on the body element inside a seamless iframe 
> should be 0. Again, this is what 90%+ of uses will expect. We shouldn't 
> require everyone using seamless iframes to have to set the body's margin 
> to 0.

Done.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] multipart/form-data filename encoding: unicode and special characters

[Ian Hickson]

On Mon, 9 Jul 2012, Julian Reschke wrote:
> 
> I agree with the methodology. However I would suggest to simply revise 
> RFC 2388.

The precise details of the process of how it's done are up to whoever 
writes the spec text, they're not really relevant to this list.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] multipart/form-data filename encoding: unicode and special characters

[Julian Reschke]

On 2012-07-09 23:01, Ian Hickson wrote:

On Thu, 3 May 2012, Evan Jones wrote:

On May 3, 2012, at 17:09 , Anne van Kesteren wrote:


Yes. I think we should define multipart/form-data directly in HTML and
thereby obsolete http://tools.ietf.org/html/rfc2388 as it is outdated
and not maintained.


Right; that would be ideal. Despite the fact that HTML5 references that
RFC, browsers don't really follow it.

I would be interested in trying to help with this, but again I would
certainly need some guidance from people who know more about the
vagaries of how the various browsers encode their form parameters /
uploaded file names, and why things got that way. It probably would not
be helpful for me to try to draft an update to the spec without getting
the right implementers on board.


If this is still something for which you have some time available, then
the starting point for anything like this would be test cases, lots and
lots of test cases. In this case, it would have to be something like a
server that echoes the precise bytes sent by the client, for a huge
variety of different setups:

  - various submission encodings
  - various form field names and types
  - various file submission filenames

...etc.

I'd be happy to advise if this is something that still interests you.


I agree with the methodology. However I would suggest to simply revise 
RFC 2388.


Best regards, Julian

Re: [whatwg] multipart/form-data filename encoding: unicode and special characters

[Ian Hickson]

On Thu, 3 May 2012, Evan Jones wrote:
> On May 3, 2012, at 17:09 , Anne van Kesteren wrote:
> >
> > Yes. I think we should define multipart/form-data directly in HTML and 
> > thereby obsolete http://tools.ietf.org/html/rfc2388 as it is outdated 
> > and not maintained.
> 
> Right; that would be ideal. Despite the fact that HTML5 references that 
> RFC, browsers don't really follow it.
> 
> I would be interested in trying to help with this, but again I would 
> certainly need some guidance from people who know more about the 
> vagaries of how the various browsers encode their form parameters / 
> uploaded file names, and why things got that way. It probably would not 
> be helpful for me to try to draft an update to the spec without getting 
> the right implementers on board.

If this is still something for which you have some time available, then 
the starting point for anything like this would be test cases, lots and 
lots of test cases. In this case, it would have to be something like a 
server that echoes the precise bytes sent by the client, for a huge 
variety of different setups:

 - various submission encodings
 - various form field names and types
 - various file submission filenames

...etc.

I'd be happy to advise if this is something that still interests you.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Elements to markup article headings

[Ian Hickson]

On Sun, 22 Apr 2012, Andrés Sanhueza wrote:
>
> There are some analog conventions that does make sense to standardize in 
> different markup languages. This is not necessarily the job of the HTML5 
> team, but it may have those issues in mind. There are a few regarding 
> the heading of newspaper articles, specific names differs, but meaning 
> is the same:
> 
> —The kicker / running head: a phrase that goes right before the
> heading, usually a short teaser or the name of a section.
> —The headline: the article title.
> —The drop deck / lead /lede: the paragraph that gives a short abstract
> of the article.
> —The byline: the line that contains meta info like the author, and/or
> the date of the article. This can go before the lead, after it or at
> the end of the article.
> 
> There have been some discussion regarding each one which have been
> more or less clarified. The way to markup that with the current
> standard:
> 
> 
> 
> 
> Kicker
> Headline
> 
> Deck
> 
> Byline
> [...]
> 

That seems fine. I would maybe go for:

   

 Kicker
 Headline
 Byline with e-mail address

Lede rest of first paragraph
...
   

...but there's a variety of possibilities here.


> It looks fine, but I'm not entirely convinced by the tag for the byline, 
> mainly because, even when it could be place differently or even multiple 
> times inside a newspaper article, when it appears at the beginning it 
> could make more sense to have it between the , but that is not 
> possible due to the rule of not having  tags with  
> descendants and vice-versa.

The byline doesn't have to be in the ; as the spec says: "Bylines 
and other information that could be suitable for both a header or a footer 
can be placed in either (or neither). The primary purpose of these 
elements is merely to help the author write self-explanatory markup that 
is easy to maintain and style; they are not intended to impose specific 
structures on authors."


> That does makes sense when sticking to what the names of the elements 
> imply, yet conceptually I see no reason a  as in "textual 
> metadata of a section" can't be inside a  ("lead of a section").

It's mostly for sanity's sake. People tend to consider their headers and 
footers as separate peers, so we like to have the validator check that 
they didn't accidentally end up nested.

HTH,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Outline Depth Does Not Correspond to Sectioning Depth?

[Ian Hickson]

On Mon, 26 Mar 2012, Hugh Guiney wrote:
>
> I am confused by the current definition of outline depth ( 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#outline-depth),
>  
> which, if I understand it correctly, states that the depth resets with 
> each sub-outline.
> 
> So, in the following:
> 
> 
>   Document Title
>   
> Section Title
> 
>   Subsection Title
> 
>   
> 
> 
> �each heading would have an outline depth of 1, yet for:
> 
> 
>   Document Title
>   Section Title
>   Subsection Title
> 
> 
> �which is, according to the spec, semantically identical to the previous 
> example, each heading would instead have an outline depth of 1, 2, and 3 
> respectively.
> 
> At least, that is how this implementation ( 
> https://github.com/hoyois/html5outliner) behaves; I raised this issue 
> with the implementor and he seems to think it is the correct behavior�if 
> so, why? Wouldn't it make more sense to have the depths be 1, 2, and 3, 
> whether explicit sections are used or not?

The spec was indeed confusing here.

I've clarified the definition of "outline depth" to make it say that it is 
the depth in the _outermost_ outline that matters (since the  element 
above is really in three outlines -- that of the , and that of each 
 -- but the depth that matters is just that of the ).

HTH,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg]

[Ian Hickson]

On Wed, 7 Mar 2012, Roland Steiner wrote:
> 
> In this regard, I would also like to try to re-ignote the discussion on 
> the fate of @-rules within 

Re: [whatwg] frame accuracy breaking case for 25fps / status of 29.97fps

[Odin Hørthe Omdal]

On Mon, 09 Jul 2012 18:46:20 +0200, adam k  wrote:

i have a 25fps video, h264, with a burned in timecode.  it seems to be  
off by 1 frame when i compare the burned in timecode to the calculated  
timecode.  i'm using rob coenen's test app at  
http://www.massive-interactive.nl/html5_video/smpte_test_universal.html  
to load my own video.


what's the process here to report issues?  please let me know whatever  
formal or informal steps are required and i'll gladly follow them.


Well, it works beautifully in that web site you reference. What do you  
think is wrong actually? I'm not so sure if the spec is the first and best  
way to go to find the error(?)


--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com

[whatwg] frame accuracy breaking case for 25fps / status of 29.97fps

[adam k]

hi whatwg, long time listener first time caller.

i have a 25fps video, h264, with a burned in timecode.  it seems to be off by 1 
frame when i compare the burned in timecode to the calculated timecode.  i'm 
using rob coenen's test app at 
http://www.massive-interactive.nl/html5_video/smpte_test_universal.html to load 
my own video.

what's the process here to report issues?  please let me know whatever formal 
or informal steps are required and i'll gladly follow them.

second question:

i'm aware that crooked framerates (i.e. the notorious 29.97) were not supported 
when frame accuracy was implemented.  in my tests, 29.97DF timecodes were 
incorrect by 1 to 3 frames at any given point.  

will there ever be support for crooked framerate accuracy?  i would be more 
than happy to contribute whatever i can to help test it and make it possible.  
can someone comment on this?  

thanks so very much for bringing frame accuracy to html5 video and bringing me 
out of the dark days of flash video and NetStream.  

adam

Re: [whatwg] [JavaScript / Web ECMAScript] Dropping the “escaped reserved words” compatibility requirement

[Odin Hørthe Omdal]

On Thu, 05 Jul 2012 10:47:46 +0200, Mathias Bynens  wrote:

Has the time come to drop this compatibility requirement?


Looks like a good time, if there truly has been no compat problems with  
doing the change Mozilla did. We'll align and try it out.


--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com