Re: [whatwg] register*Handler and Web Intents
Ian, As you can tell by the delay, we've (James Hawkins, Paul Kinlan, myself, others working on web intents for Chromium) been carefully reading your email and talking about the issues you bring up. I think we agree on most things, except for some small but important points. Considering RPH, RCH, and web intents all part of the same feature is a good plan. Even if the APIs are different (but parallel), having users able to think of them the same way is the right track. That is, the UA presentation of the features should be indistinguishable so that users can leverage familiarity with UI models of permission grants, manipulating defaults and installed options, and make correct attribution judgments easily when the features are used. On Mon, Apr 2, 2012 at 4:23 PM, Ian Hickson wrote: > 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. For RPH, agreed that passing the URL is pretty much the only possible approach. For RCH, web intents allows us to do better than this: we can pass the content directly, in a Blob, rather than passing the URL, thus decoupling the service from the (possibly sensitive) URL from which the intent was triggered. That isn't always the right plan -- for feed URLs, passing the URL is an important feature enabler for a feed reader to deal with the content. Anyway, mostly pointing out that considering these together is a vehicle for more fine-grained control of the coupling. If anything, this intertwines them more closely. > Thus we reach a point where we can describe all three as a common set of > registration features: Agreed. This seems like a big win -- considering the registrations as different potential capabilities of the same service feels like a much simpler scenario for users. > 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: > > 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" > > > > [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 elment is seen again, which > could happen that very same page load). This all sounds good. The argument about unregistration is what really compels the imperative API, I think. Allowing (same-origin) pages to unregister handlers imperatively is key to reliably being able to not require a failed intent dispatch to a stale URL to unregister it. (Otherwise it'd be too easy to end up compelling the full registration-checking protocol on basically every page load to see if the absence of an tag means deregistration.) Another nicety is that RPH/RCH handlers can be invoked imperatively with navigator.startActivity. Our remaining discomfort here is with isIntentHandlerRegistered(), and for similar reasons to the fingerprinting qualities of isProtocolHandlerRegistered(). That is, we'd prefer that web content simply call registerProtocolHandler blindly, similar to what a declarative registration would do, and let the UA sort out whether the user ought to be shown any kind of registration UI. This does, however, impose
Re: [whatwg] readyState transitions when aborting a document
On Thu, Apr 19, 2012 at 2:43 PM, Henri Sivonen wrote:
> * Is there a way to abort a document load in IE without causing
> immediate navigation away from the document? IE doesn't support
> window.stop().
Yes. document.execCommand("Stop")
> * Does Web compatibility ever require a transition from "loading" to
> "complete" without an intermediate "interactive" state? (Both chrome
> and Firefox as shipped make such transitions, but those might be
> bugs.)
I have no evidence to say anything sure here, but I doubt Web compat
requires transitions from "loading" to "complete". What actually
happens varies a lot.
> * Should the aborted documents stay in the "loading" state forever
> like the spec says or should they reach the "complete" state
> eventually when the event loop spins?
Gecko and WebKit disagree.
> * Should window.stop() really not abort the parser like the spec
> seems to suggest?
Looks like Opera is alone with the non-aborting behavior. The spec is wrong.
> * Should reaching "complete" always involve firing "load"?
Not in WebKit.
> * Should reaching "interactive" always involve firing "DOMContentLoaded"?
Probably.
> * Does anyone have test cases for this stuff?
Demos: http://hsivonen.iki.fi/test/moz/readystate/
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Thu, Apr 19, 2012 at 11:28 PM, Maciej Stachowiak wrote: > You could also address this by adding a way to be notified when the > contents of an ImageData are available without blocking. That would work > with both vanilla getImageData and the proposed getImageDataHD. It would > also give the author the alternative of just blocking (e.g. if they know > the buffer is small) or of sending the data off to a worker for processing. > This would result in people writing poor code, based on incorrect assumptions. It doesn't matter how big the buffer is; all that matters is how long the drawing calls before the getImageData take. For example, if multiple canvases are being drawn to (eg. on other pages running in the same thread), they may share a single drawing queue. Any time you retrieve image data synchronously, and it happens to require a draw flush, you freeze the UI for all pages sharing that thread. Why is that okay for people to do? We should know better by now than to expose APIs that encourage people to block the UI thread, after spending so much time trying to fix that mistake in early APIs. (This should expose a synchronous API in workers if and when Canvas makes it there, of course, just like all other APIs.) -- Glenn Maynard
Re: [whatwg] URL query component
On 2012-04-20 14:37, And Clover wrote: On 2012-04-20 09:15, Anne van Kesteren wrote: Currently browsers differ for what happens when the code point cannot be encoded. What Gecko does [?%C2%A3] makes the resulting data impossible to interpret. What WebKit does [?%26%23163%3B] is consistent with form submission. I like it. I do not! It makes the data impossible to recover just as Gecko does... in fact worse, because at least Gecko preserves ASCII. With the WebKit behaviour it becomes impossible to determine from an pure ASCII string '£' whether the user really typed '€' or '£' into the input field. It has the advantage of consistency with the POST behaviour, but that behaviour is an unpleasant legacy hack which encourages a misunderstanding of HTML-escaping that promotes XSS vulns. I would not like to see it spread any further than it already has. +1 Indeed. I think this is a case where you want to fail early (for some value of "fail"); so maybe substituting with "?" makes most sense. Do any servers *expect* the Webkit behavior? If they do so, why don't they just fix the pages they serve to use UTF-8 to get consistent behavior throughout? Best regards, Julian
Re: [whatwg] URL query component
On Fri, 20 Apr 2012 14:37:10 +0200, And Clover wrote: On 2012-04-20 09:15, Anne van Kesteren wrote: Currently browsers differ for what happens when the code point cannot be encoded. What Gecko does [?%C2%A3] makes the resulting data impossible to interpret. What WebKit does [?%26%23163%3B] is consistent with form submission. I like it. I do not! It makes the data impossible to recover just as Gecko does... in fact worse, because at least Gecko preserves ASCII. With the WebKit behaviour it becomes impossible to determine from an pure ASCII string '£' whether the user really typed '€' or '£' into the input field. You have the same problem with Gecko's behavior and multi-byte encodings. That's actually worse, since an erroneous three byte sequence will put the multi-byte decoders off. It has the advantage of consistency with the POST behaviour, but that behaviour is an unpleasant legacy hack which encourages a misunderstanding of HTML-escaping that promotes XSS vulns. I would not like to see it spread any further than it already has. It's both GET and POST. So really the only difference here is manually constructed URLs. Also, I think we should flag all non-utf-8 usage. This is mostly about deciding behavior for legacy content, which will already be broken if it runs into this minor edge case. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] URL query component
On 2012-04-20 09:15, Anne van Kesteren wrote: Currently browsers differ for what happens when the code point cannot be encoded. What Gecko does [?%C2%A3] makes the resulting data impossible to interpret. What WebKit does [?%26%23163%3B] is consistent with form submission. I like it. I do not! It makes the data impossible to recover just as Gecko does... in fact worse, because at least Gecko preserves ASCII. With the WebKit behaviour it becomes impossible to determine from an pure ASCII string '£' whether the user really typed '€' or '£' into the input field. It has the advantage of consistency with the POST behaviour, but that behaviour is an unpleasant legacy hack which encourages a misunderstanding of HTML-escaping that promotes XSS vulns. I would not like to see it spread any further than it already has. cheers, -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ gtalk:chat?jid=bobi...@gmail.com
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Tue, Jan 10, 2012 at 2:10 AM, Ian Hickson wrote: > On Tue, 31 May 2011, Henri Sivonen wrote: >> >> Recently, there was discussion about changing media element state in the >> same task that fires the event about the state change so that scripts >> that probe the state can make non-racy conclusions about whether a >> certain event has fired already. >> >> Currently, there seems to be no correct non-racy way to write code that >> probes a document to determine if DOMContentLoaded or load has fired and >> runs code immediately if the event of interest has fired or adds a >> listener to wait for the event if the event hasn't fired. >> >> Are there compat or other reasons why we couldn't or shouldn't make it >> so that the same task that fires DOMContentLoaded changes the readyState >> to "interactive" and the same task that fires load changes readyState to >> "complete"? > > Fixed for 'load'. I don't see a good way to fix this for > 'DOMContentLoaded', unfortunately. It turns out that Firefox has accidentally been running defer scripts after DOMContentLoaded. I haven't seen bug reports about this. Embracing this bug might offer a way to always keep the readystatechange to "interactive" in the same task that fire DOMContentLoaded. See http://hsivonen.iki.fi/test/moz/readystate/defer-script.html -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[whatwg] URL query component
The URL query component for URLs found in HTML (exact set still be to be defined I think) uses the page encoding when the page encoding is not utf-8/utf-16 (then it uses utf-8). E.g. "?€" maps to "?%80" in a windows-1252 encoded page. Currently browsers differ for what happens when the code point cannot be encoded. E.g. "?€" Opera uses "?". Internet Explorer uses "?" (but when the URL hits the network layer, not when you inspect it via script). WebKit uses "&#...;". Gecko encodes it using utf-8. What Gecko does makes the resulting data impossible to interpret. What WebKit does is consistent with form submission. I like it. Also, given that encoding behavior is not exposed besides form submission and URLs, consistently using "&#...;" for code points not represented in legacy encodings makes sense to me. Am I missing something? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] IBM864 mapping of Encoding Standard
On Fri, 20 Apr 2012 09:58:52 +0200, Makoto Kato wrote: I have a question of Encoding standard of http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html. Gecko supports IBM864, but it is different of old IBM864. It is modified to support euro sign due to requested by IBM ([1] and [2]). Gecko also supports data:text/html;charset=ibm864,%25 0x25 -> U+066A which is probably worse as it changes the ASCII range. You submit encoding detail [3] in repository, but this spec seems to be old spec of IBM864. I think that we should use new mapping supported euro sign [4] instead of old mapping. Or we should remove IBM code pages from spec. How do you think? Does that mean you want to remove the encoding from Gecko? That would work for me. It is currently not supported by Opera either. Alternatively mapping 0xA7 to U+20AC works for me too, but I don't want it to tinker with the ASCII range. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=240596 [2] http://www-01.ibm.com/software/globalization/cp/cp00864.html [3] http://dvcs.w3.org/hg/encoding/raw-file/tip/index-ibm864.txt [4] ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00864.txt -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] IBM864 mapping of Encoding Standard
Hi Anne. I have a question of Encoding standard of http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html. Gecko supports IBM864, but it is different of old IBM864. It is modified to support euro sign due to requested by IBM ([1] and [2]). Although ICU supports IBM864, this doesn't map euro sign to 0xA7. Since some implementations of web browser use ICU, it may be different per browser if using ICU. You submit encoding detail [3] in repository, but this spec seems to be old spec of IBM864. I think that we should use new mapping supported euro sign [4] instead of old mapping. Or we should remove IBM code pages from spec. How do you think? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=240596 [2] http://www-01.ibm.com/software/globalization/cp/cp00864.html [3] http://dvcs.w3.org/hg/encoding/raw-file/tip/index-ibm864.txt [4] ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00864.txt -- Makoto Kato
