Re: [whatwg] Readiness of script-created documents
On Fri, Mar 30, 2012 at 8:26 PM, Jonas Sicking jo...@sicking.cc wrote: On Friday, March 30, 2012, Henri Sivonen wrote: On Fri, Jan 13, 2012 at 2:26 AM, Ian Hickson i...@hixie.ch wrote: Jonas is correct. Since there was no interop here I figured we might as well go with what made sense. I'm somewhat unhappy about fixing IE-introduced APIs to make sense like this. The implementation in Gecko isn't particularly good. When trying to make it better, I discovered that doing what IE did would have lead to simpler code. That's not a particularly strong argument. The question is what's better for authors. Gratuitously changing features introduced by IE does not help authors one day have to support the old IE behavior for years. Either authors don't use the API in the uninteroperable situation or they will have to deal with different browsers returning different things. The easiest path to get to the point where all browsers in use return the same thing would have been for others to do what IE did. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Readiness of script-created documents
On Mon, Apr 2, 2012 at 10:12 AM, Henri Sivonen hsivo...@iki.fi wrote: Gratuitously changing features introduced by IE does not help authors one day have to ...when they have to... -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Readiness of script-created documents
On Mon, Apr 2, 2012 at 12:12 AM, Henri Sivonen hsivo...@iki.fi wrote: On Fri, Mar 30, 2012 at 8:26 PM, Jonas Sicking jo...@sicking.cc wrote: On Friday, March 30, 2012, Henri Sivonen wrote: On Fri, Jan 13, 2012 at 2:26 AM, Ian Hickson i...@hixie.ch wrote: Jonas is correct. Since there was no interop here I figured we might as well go with what made sense. I'm somewhat unhappy about fixing IE-introduced APIs to make sense like this. The implementation in Gecko isn't particularly good. When trying to make it better, I discovered that doing what IE did would have lead to simpler code. That's not a particularly strong argument. The question is what's better for authors. Gratuitously changing features introduced by IE does not help authors one day have to support the old IE behavior for years. Either authors don't use the API in the uninteroperable situation or they will have to deal with different browsers returning different things. The easiest path to get to the point where all browsers in use return the same thing would have been for others to do what IE did. Everyone returning the same thing isn't the only goal. First of all what's the purpose of all browsers doing the same thing if that same thing isn't useful? Second, you are assuming that people are actually aware of this edge case and account for it. Here it seems just as likely to me that generic code paths would result in buggy pages given IEs behavior, and correct behavior given the specs behavior. Third, if no-one is hitting this edge case, which also seems quite plausible here, then it having a while longer without interoperability won't really matter what we do and doing the most useful thing seems like the best long-term goal. / Jonas
Re: [whatwg] Tables, headers and bodies
On 01 Apr 2012 at 21:15, Jose Fandos iaminlon...@gmail.com wrote: Can anyone point to any discussions about table headers and table bodies and how to deal with having a fixed header and a scrollable body? I've done a number of searches but might not be using the right terms to unearth any previous discussion in this regard. The idea is a quite common situation in software interfaces of all kinds where the headers will always be visible while the table rows (table body) will scroll. The only way I found to do this is to have two tables, fixed cell widths, overflow hidden, and textOverflow ellipsis. There is additional CSS to get the two tables to look like one. -- Cheers -- Tim
Re: [whatwg] Invalid values of dir attribute causing change in appearance?
On Tue, 24 Jan 2012, L. David Baron wrote:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#bidirectional-text
specifies that UA style sheets should have the rule:
[dir] { unicode-bidi: embed; }
This implies that invalid values of the dir attribute should cause a
change in presentation. This seems wrong to me, on the general
principle that invalid values of attributes should be ignored. [...]
I tend to think that only the known values of the dir attribute should
cause the unicode-bidi:embed styling.
Fixed as suggested for all instances of [dir] in the UA style sheet.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] register*Handler and Web Intents
On Tue, 6 Dec 2011, James Hawkins wrote: One of the critical pieces of the API is a declarative registration which allows sites to declare which intents they may be registered for. The current draft of the API calls for a new HTML tag, intent, the attributes of which describe the service registration [...] Rather than an element just for Web Intents, I think we'd be better off with an element that can be used for all the registration mechanisms: registerProtocolHandler(), registerContentHandler(), and Web Intents. Similarly, rather than Web Intents only being declarative, we should follow the pattern set by registerProtocolHandler() and register- ContentHandler() and also support an API. This would make these three mechanisms consistent with each other such that they can be considered a single feature, not three features. Looking at the three features, it seems they break down as follows: a handler registered using registerContentHandler() triggers when a URL with a particular type is opened, and results in the URL being passed to another URL that is opened. a handler registered using registerProtocolHandler() triggers when a URL with a particular scheme is opened, and results in the URL being passed to another URL that is opened. a handler registered using Web Intents triggers when a method is invoked on another page, and results in a URL being opened and its JavaScript context being given the information passed to the method. In the first two, the behaviour can be implemented server-side or client-side; in the last case the behaviour must be done in JS. We can pretend that in the case of the first two, it's equivalent to an open action with the URL as the data. This would mean that the intent data, in the case of a URL open, would just be the URL string. We can similarly pretend that in the case of the latter, it's fetching the page like in the %s case, but since there's no %s, it doesn't put the data in the URL. Or alternatively, we can say that because the data is a structured clone rather than a URL, you replace the %s, if any, with the empty string. Thus we reach a point where we can describe all three as a common set of registration features: 1. select type of handler: - url - structured clone 2. select action - open - share - edit - etc... 3. optionally select one other further filter - type - scheme (only allowed for url handlers) 4. select URL to use as handler 5. select user-facing title 6. select disposition (replace page, new page, or overlay) When a URL is opened that matches a registered handler for the open action and the appropriate scheme or type, imply an intent for that URL handler, with any returned result being discarded. The handling can then be a single mechanism for all of the above: 1. If it's a URL handler, replace %s with the URL. 2. Set up the browsing context per the disposition. 3. Open the URL. 4. Set up the Window.intent API. So, what information would we need for registration? payload type: a url, or an object to clone action: a string filter: either a MIME type, or a scheme url: the url to call title: the user-visible name of the handler disposition: how to show the handler (replace, new tab, popup overlay) My suggestion then would be to add an element similar to what you suggest, as well as an API similar to the existing one. The element could be something like: intent action=edit intent action, e.g. open or edit, default share type=image/png MIME type filter [1], default */* scheme=mailto Scheme filter [1] [2], default omitted href= Handler URL [2], default title=Foo Handler user-visible name, required attribute disposition=replace, new, or overlay, default overlay /intent [1] Only one of type= and scheme= is allowed. [2] scheme= is only allowed if href= contains %s. The API could be something like: void registerIntentHandler(DOMString action, DOMString type, DOMString url, DOMString title, DOMString disposition); DOMString isIntentHandlerRegistered(DOMString action, DOMString type, DOMString url); void unregisterIntentHandler(DOMString action, DOMString type, DOMString url); The disposition of registerContentHandler() and registerProtocolHandler() would always be replace. The /url/ argument of registerProtocolHandler() would not be allowed to contain %s. A handler, once registered, would remain so until it was explicitly removed with unregisterIntentHandler() or removed by the user, as now for the other handler APIs; or, for registrations done with the declarative form, would remain until the user returns to the same page and the page returns a 200, 404, or 410 response (at which point it would be unregistered until such time as the intent elment is seen again, which could happen that very same page
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, 26 Sep 2011, Tyler Close wrote:
I was recently experimenting with the registerProtocolHandler (RPH) API
and came across a couple of security gotchas that make it hard to safely
use the API. One of these is already known, but AFAICT, hasn't been
fixed yet. I haven't seen the other discussed yet.
The Mozilla blog post that introduces the registerProtocolHandler API
makes use of window.parent.postMessage to send a response from the RPH
handler back to the client page.
I presume it uses this in conjunction with an a href= link with a
target= attribute to load the handler in an iframe.
In the example code, the targetOrigin for this postMessage invocation is
'*', while also noting that this is not secure. AFAICT, there is no API
that the intent handler can reliably use to determine the correct
targetOrigin for this postMessage invocation.
How can the origin be anything other than the origin of the page that
triggered the link?
I suggest fixing this problem by adding a new readonly DOMString that
contains the correct origin for the postMessage invocation; perhaps
document.origin. So the response invocation would then be coded as:
window.parent.postMessage('my response data', document.origin);
Perhaps a different name or location is better for this field, so I'll
defer to the editor's judgment.
You can work out your own origin from window.location's members, but I
don't see how this helps you determine the origin of your parent. There's
a separate thread about adding a way to obtain your parent's origin, but
again, I don't see why you would need it in this case. Can you elaborate
on what the attack scenario you are envisaging is?
The second problem with RPH is that the handler page doesn't have a
way of reliably getting the URL of the content to be handled from the
browser. In order to work in offline scenarios, the RPH handler must
put the %s placeholder in the fragment of its handler's URL.
It's not clear to me that it makes sense to have an offline protocol
handler. What kind of protocol do you have in mind?
Unfortunately, this means that other content in the browser could
modify the content URL before the handler reads it.
Well, any content can load any URL, so it doesn't matter whether the URL
is in the fragment identifier or the path or anything else, surely.
For example, an attacker could open a window on a victim web page. The
victim web page then opens an iframe on a content URL that triggers
RPH. The attacker then navigates the iframe so that its
window.location contains a different content URL.
How can the attacker navigate that iframe? Surely it would not be allowed
to navigate it, per the allowed to navigate definition in HTML.
The intent handler sees a request coming from the victim page, but with
a content URL specified by the attacker. A related problem is that the
intent handler has no way to distinguish whether its URL was loaded via
the browser's RPH handling, or whether the client page directly
navigated to the intent handler's URL. Both of these problems could be
fixed by adding another readonly DOMString to the API that contains the
%s data for the RPH invocation.
I don't understand why it matters how the URL was invoked.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On 4/2/12 7:39 PM, Ian Hickson wrote: For example, an attacker could open a window on a victim web page. The victim web page then opens aniframe on a content URL that triggers RPH. The attacker then navigates theiframe so that its window.location contains a different content URL. How can the attacker navigate that iframe? Surely it would not be allowed to navigate it, per the allowed to navigate definition in HTML. As far as I can tell UAs seem to allow walking window.frames for any window you have a reference to without performing any same-origin checks, so you can walk your way down the frame hierarchy and then set location.href, which is allowed cross-origin. I don't see any sort of allowed to navigate check happening on the href set in UAs, but maybe I'm testing it wrong? -Boris
Re: [whatwg] [media] startOffsetTime, also add startTime?
On Fri, 9 Mar 2012, Philip Jägenstedt wrote: On Thu, 08 Mar 2012 19:16:40 +0100, Ian Hickson i...@hixie.ch wrote: On Thu, 8 Mar 2012, Philip Jägenstedt wrote: I suggest the property offsetTime, defined as the stream time in seconds which currentTime and duration are relative to. I don't understand what this means. The currentTime is relative to the media timeline, which is UA-defined and should be based on the media timeline. The BBC wrote a blog post [1] about how currentTime varies between Firefox and Chrome. Opera does the same as Firefox here. You're right, however, that the way media timeline doesn't make any guarantee that currentTime starts at 0 or that duration is the duration. I think that the implementations predate the media timeline concept, and I agree with the BBC blog post that the Opera/Firefox behavior is better. Controls written assuming that currentTime goes from 0 to duration won't break and duration will actually mean duration. Controls written assuming that currentTime goes from 0 to duration are going to look mighty ugly when dealing with infinite streams where the browser is only buffering the last 30 minutes, DVR-style. I don't think this is a sane assumption. Or to put it another way: currentTime does always go from 0 to duration, and duration could be Infinity; but at any particular time, only a part of that is a seekable range. In practice it would often be understood as the time since the server began streaming and would be useful to sync live streams with out-of-band content simply by letting the out-of-band content be relative to the start of the stream. That should be zero. I can change that to a must if you like; it's a should because in some cases (e.g. MJPEG) you don't know what the media timeline is or how to interpret it, so there's no way to do it. Which should are you referring to here? If the media resource somehow specifies an explicit timeline whose origin is not negative, then the media timeline should be that timeline and In the absence of an explicit timeline, the zero time on the media timeline should correspond to the first frame of the media resource. I really don't know what startOffsetTime is intended for. AFAICT it's a piece of metadata that you could just as well provide out-of-band, but for convenience it is exposed via the DOM API. I think it could be handy to have and would like to implement it, but I don't understand if it's any different from other metadata like producer or location of a video. The startOffsetTime is useful for controllers who want to display a controller with real times, e.g. like TiVo's DVR UI, even when the underlying media resource has some more or less arbitrary timeline. e.g. if a TV station starts broadcasting on some Friday at 2pm, that would be its zero time for its timeline, but eight months later, a user joining that stream doesn't care that the stream is 21 megaseconds old -- they just want to see 14:20 as the time that corresponds to what was streaming at 2:20pm. However, knowing the date of a video is still useful, potentially even for the streaming case, so we do want to expose the DateUTC field from WebM. However, startOffsetTime is a bad name for it, since it's not using the same unit as currentTime. I suggest offsetDate, to go with offsetTime. I don't mind renaming startOffsetTime if people think that would help. I don't think offsetDate is any clearer though. How about mediaTimelineOriginDate? Simply originDate or startDate, perhaps? Ok, I renamed it to startDate. It could also do with a good example. The spec says: If the media resource specifies an explicit start time and date, then that time and date should be considered the zero point in the media timeline; the timeline offset will be the time and date, exposed using the startOffsetTime attribute. I interpret this as a date at currentTime=0 in the spec's definition of currentTime Right. and currentTime=-initialTime (unless media fragments are used) in the Opera/Firefox definition of currentTime. Not sure what this means. However, there's a weird spec example which can lead one into thinking otherwise: The startOffsetTime attribute would return a Date object with a time corresponding to 2010-03-20 23:15:00 UTC. However, if a different user agent connected five minutes later, it would (presumably) receive fragments covering timestamps 2010-03-20 23:20:00 UTC to 2010-03-21 00:05:00 UTC and 2010-02-12 14:25:00 UTC to 2010-02-12 14:35:00 UTC, and would expose this with a media timeline starting at 0s and extending to 3,300s (fifty five minutes). This seems like a rather atypical streaming scenario. It would be a lot nicer if the single example of startOffsetTime was for the common scenario where each client gets the same stream that thus has the same timeline and the same
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, 2 Apr 2012, Boris Zbarsky wrote: On 4/2/12 7:39 PM, Ian Hickson wrote: For example, an attacker could open a window on a victim web page. The victim web page then opens aniframe on a content URL that triggers RPH. The attacker then navigates theiframe so that its window.location contains a different content URL. How can the attacker navigate that iframe? Surely it would not be allowed to navigate it, per the allowed to navigate definition in HTML. As far as I can tell UAs seem to allow walking window.frames for any window you have a reference to without performing any same-origin checks, so you can walk your way down the frame hierarchy and then set location.href, which is allowed cross-origin. I don't see any sort of allowed to navigate check happening on the href set in UAs, but maybe I'm testing it wrong? Ah, yes, good point, I forgot that the attacker would have a reference to the Window object. Seems like it would be just as easy to just register a protocol handler though. I mean, why would the victim assume it trusts the handler in this scenario? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
