Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Sep 30, 2013 at 5:42 PM, Rik Cabanier caban...@gmail.com wrote: Where does it say in the spec that if you have assistive technology enabled, focus rings should not be drawn? if as a web author I call drawCustomFocusRing and it returns false, I'm not supposed to draw anything according to the spec. That's what doesn't make sense to me. It would take an element in fallback content as an argument. That would allow assistive technology to be notified. As Ian pointed out, the accessibility software could do that. scrollPathIntoView can't be used to notify accessibility software of the focused object location as-is because it doesn't have an element to fire on, and it doesn't know if the scrolling is because of focus or not. If we added a canvas fallback element as a parameter to scrollPathIntoView, I don't think we'd need drawCustomFocusRing.
[whatwg] onclose events for MessagePort
Hi everyone, We're coming across a need to get notified when the other side of a channel goes away because the user navigates away from the page, or if the page is killed by the OS, etc. Currently a workaround is for the application to handle the unload event and send a message on its channel letting the other side know that it's going to die, but that's obviously not good enough if the application is terminated abruptly (e.g., crashes.) We proposed an onclose event on MessagePort to handle this case [1] and it was rejected because that would make the GC behavior observable (in case the port on the other side is garbage collected.) But it seems like tying the lifetime of MessagePorts to the lifetime of their owner document will fix that problem. Is that going to be an acceptable solution? [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23327 Thanks! -- Ehsan http://ehsanakhgari.org/
Re: [whatwg] onclose events for MessagePort
On Tue, 1 Oct 2013, Ehsan Akhgari wrote: We're coming across a need to get notified when the other side of a channel goes away because the user navigates away from the page, or if the page is killed by the OS, etc. What is that need? Can you elaborate? Currently a workaround is for the application to handle the unload event and send a message on its channel letting the other side know that it's going to die, but that's obviously not good enough if the application is terminated abruptly (e.g., crashes.) If the browser crashes, it's not going to be able to send messages anyway, so I'm not sure that makes sense. When would the browser be able to send a message, but not able to properly handle unload? We proposed an onclose event on MessagePort to handle this case [1] and it was rejected because that would make the GC behavior observable (in case the port on the other side is garbage collected.) But it seems like tying the lifetime of MessagePorts to the lifetime of their owner document will fix that problem. Is that going to be an acceptable solution? The problem with that is that there'd be no real way to know what the owner Document is for an author. Suppose the port is sent to an iframe, and then just handed over from that iframe to another iframe by just passing it in an argument in a function, or whatnot (i.e. not transferring it). Now the port is nowhere near the document that owns it. That's why there's in fact no concept of port ownership in the spec. Also, it would force message ports to survive being GCed up to the end of the document's lifetime, which would essentially mean every port always leaks until the document is closed. This is fine for many uses of ports, but ports are also designed to be used as lightweight capability grants, which can get vended like candy. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] onclose events for MessagePort
On 10/01/2013 06:37 PM, Ehsan Akhgari wrote: Hi everyone, We're coming across a need to get notified when the other side of a channel goes away because the user navigates away from the page, or if the page is killed by the OS, etc. Currently a workaround is for the application to handle the unload event and send a message on its channel letting the other side know that it's going to die, but that's obviously not good enough if the application is terminated abruptly (e.g., crashes.) We proposed an onclose event on MessagePort to handle this case [1] and it was rejected because that would make the GC behavior observable (in case the port on the other side is garbage collected.) But it seems like tying the lifetime of MessagePorts to the lifetime of their owner document will fix that problem. Is that going to be an acceptable solution? I don't understand what the lifetime of MessagePorts to the lifetime of their owner document means in case of workers. And we sure want to delete MessagePort objects if nothing from JS side is keeping it, or the port it is connected to alive. -Olli [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23327 Thanks! -- Ehsan http://ehsanakhgari.org/
Re: [whatwg] onclose events for MessagePort
On 10/1/13 12:58 PM, Ian Hickson wrote: If the browser crashes, it's not going to be able to send messages anyway This concept of the browser... The situation being considered here is that you have two web pages in two different OS-level processes that have a MessageChannel between them. One of the OS-level processes crashes (and hence obviously can't send any more messages, as you note). The other one would like to know that its counterparty is gone. How should it find out? That's the problem I think Ehsan is trying to solve. -Boris
Re: [whatwg] onclose events for MessagePort
On Tue, 1 Oct 2013, Boris Zbarsky wrote: On 10/1/13 12:58 PM, Ian Hickson wrote: If the browser crashes, it's not going to be able to send messages anyway This concept of the browser... The situation being considered here is that you have two web pages in two different OS-level processes that have a MessageChannel between them. One of the OS-level processes crashes (and hence obviously can't send any more messages, as you note). The other one would like to know that its counterparty is gone. How should it find out? That's the problem I think Ehsan is trying to solve. Crashing is non-conforming. Having features explicitly to handle the non-conforming case is a bit weird. :-) How often are we really expecting one tab to be talking to another tab, and then that tab crashes, and the author was able to prepare code to handle that gracefully, in a production environment? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] onclose events for MessagePort
On Tue, Oct 1, 2013 at 8:45 PM, Ian Hickson i...@hixie.ch wrote: Crashing is non-conforming. rules-lawyer href=http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#conformance-requirements; Terminating the process with SIGSEGV if a page exceeds an implementation-limit on memory usage seems perfectly conforming to me. /rules-lawyer Whether the case presents real-world difficulties for authors sounds like the more interesting question here.
Re: [whatwg] onclose events for MessagePort
On Tue, Oct 1, 2013 at 1:45 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 1 Oct 2013, Boris Zbarsky wrote: On 10/1/13 12:58 PM, Ian Hickson wrote: If the browser crashes, it's not going to be able to send messages anyway This concept of the browser... The situation being considered here is that you have two web pages in two different OS-level processes that have a MessageChannel between them. One of the OS-level processes crashes (and hence obviously can't send any more messages, as you note). The other one would like to know that its counterparty is gone. How should it find out? That's the problem I think Ehsan is trying to solve. Crashing is non-conforming. Having features explicitly to handle the non-conforming case is a bit weird. :-) Well, I'm not talking about content intentionally crashing. Out of memory crashes are an example of the kind of crash which you can't really prevent. How often are we really expecting one tab to be talking to another tab, and then that tab crashes, and the author was able to prepare code to handle that gracefully, in a production environment? That is not the only use case. Another use case which is currently more interesting for us in Firefox OS is to know when the connection to another application such as the music player is dead because the other side suffered an OOM crash for example, so that we can update the UI letting the user know that the music is no longer playing. Cheers, -- Ehsan http://ehsanakhgari.org/
Re: [whatwg] onclose events for MessagePort
On 10/1/13 1:45 PM, Ian Hickson wrote: Crashing is non-conforming. That's not useful. Crashing (or rather being killed by the OS) happens all the time on tablets and phones. You get killed for using too much memory, for not being active while other stuff is using too much memory, for just not being active, etc. So in practice this needs to be handled somehow, no matter how much we'd like to avoid thinking about it. How often are we really expecting one tab to be talking to another tab, and then that tab crashes, and the author was able to prepare code to handle that gracefully, in a production environment? On phones? We should be expecting the former (tab gets killed) pretty often. How often the latter will happen depends on how much we give authors in the way of tools to handle it. -Boris
Re: [whatwg] onclose events for MessagePort
On Tue, 1 Oct 2013, Boris Zbarsky wrote: On 10/1/13 1:45 PM, Ian Hickson wrote: Crashing is non-conforming. That's not useful. Hence the smiley. How often are we really expecting one tab to be talking to another tab, and then that tab crashes, and the author was able to prepare code to handle that gracefully, in a production environment? On phones? We should be expecting the former (tab gets killed) pretty often. How often the latter will happen depends on how much we give authors in the way of tools to handle it. How often do we expect two tabs to be talking to each other though? Is that even possible on phone browsers? Anyway, I'm happy to support this in principle. I should correct something I said earlier in this thread. I said MessagePorts don't have owners. This is incorrect. My apologies. We could indeed have some message that is sent when the owner goes away. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] onclose events for MessagePort
On 10/1/13 2:11 PM, Ian Hickson wrote: How often do we expect two tabs to be talking to each other though? Or a page to an out-of-process subframe? How often do we expect MessageChannel to be used at all? Is that even possible on phone browsers? Sure is in Firefox and FirefoxOS. Anyway, I'm happy to support this in principle. OK, good. ;) -Boris
Re: [whatwg] Bug in 12.2.5.4.8 (The text insertion mode) when invoking the spin the event loop algorithm
On Fri, 27 Sep 2013, James Robinson wrote:
12.2.5.4.8 (The text insertion mode) defines an following algorithm
for dealing with inline script tags that aren't ready to execute when
parsed. I believe there are some subtle bugs with the way the algorithm
is specified. More importantly, the invocation of the spin the event
loop algorithm makes it harder to reason about the system as a whole.
The algorithm in question runs when parsing a /script at a script
nesting level (i.e. not one generated by document.write()):
They might have been generated by document.write(), it's just that they
aren't being executed re-entrantly.
Step 3 spins the event loop. The issue is that while the tokenizer is
blocked other tasks can run whenever the event loop is spun and cause
changes that make the rest of the algorithm incorrect. For example,
consider:
!DOCTYPE html
script
window.setTimeout(function() {
document.write(Goodbye);
}, 50);
/script !-- i'm assuming you were missing this here --
link rel=stylesheet type=text/css href=long_loading.css/link
!-- note that /link isn't valid, it is just ignored --
script
window.alert(Hello);
/script
The algorithm in question will run when parsing the last /script. The
second script can't execute until the stylesheet loads, so the spec
spins the event loop until that happens. However, if the setTimeout
fires before long_loading.css loads then the document.write() call will
first perform an implicit document.open(), since there is no insertion
point, and blow away the entire Document.
True.
This cancels any pending tasks but doesn't (as far as I can tell) cancel
already started tasks.
There's only ever one already-started task. Spin the event loop stops
the previous task, waits until a condition is met, and then queues a new
task that is the continuation of the previous task. While the event loop
is spinning, that original task is ended.
By my reading of the spec, the rest of the steps of the algorithm should
still run and the script should execute.
This appears to be true. The condition is the parser's Document has no
style sheet that is blocking scripts and the script's ready to be
parser-executed flag is set, which becomes true when the link element
is removed from the document by document.open(), if nothing else.
It's an interesting case. Every other instance where spin the event loop
can become moot is a case where the Document also stops being active,
meaning the task that spin the event loop then adds to the task queue
never executes (only tasks for active Documents get executed).
I considered making the spin the event loop algorithm be canceled by the
document.open() algorithm, but that would mean that if showModalDialog()
is called and then its document is document.open()ed, it'd never return,
which isn't what actually happens.
So I just made the specific case of the parser spin the event loop
returning check whether the parser in question has been aborted; if it
has, then it just stops without running the script.
I propose that instead of spinning the event loop, we instead have step
3 enter an asynchronous section if the script isn't ready to run yet
which queues a task once the script is ready to run. Since this
algorithm only runs at a script nesting level of zero this is a fairly
minor tweak in overall behavior, but I believe it means that invoking
the tokenizer can never spin the event loop which is a nice property to
have.
Isn't that more or less exactly what spin the event loop does? I don't
understand how this would solve the problem. You'd still end up resuming
the parser after document.open() nukes the Document, leading to the script
running and so forth.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms: input type=file and directory tree picking
On Thu, 29 Aug 2013, Jonas Sicking wrote: On Thu, Aug 29, 2013 at 2:45 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Aug 2013, Jonas Sicking wrote: On Thu, Aug 29, 2013 at 1:20 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 2 Aug 2013, Jonathan Watt wrote: I'm working on Mozilla's implementation of input type=file to allow the user to pick a directory. The idea would be that the files in that directory and its subdirectories would be added to the HTMLInputElement.files FileList. This seems to be dangerous in that it makes it really easy for the user to select a single item that expands into tens of thousands if not millions of files on a remote disk, which then all have to be synchronously enumerated to get the count so that code can then itself enumerate through the entire list. We don't have to do any enumeration synchronously. It can all happen off the main thread. The .click() API is asynchronous. It's asynchronous to the JS, sure, but at the end of the day the user can't get any work done until it's complete. It's synchronous as far as the user is concerned. Sure. The alternative is that the user attaches each file separately. That's not the only alternative. For example, a third alternative is that the user's selection (e.g. a directory) is returned quickly, not pre-expanded, and then any uploading happens in the background with the author script doing the walk and uploading the files. So you wouldn't be able to pick a file and a directory as in the example above? That seems unfortunate... Unfortunately most OSs doesn't have support for filepickers that can select either a file or a directory. True. From a UI perspective it's kind of weird that the user has to decide which he wants, though. Similarly, from an authoring perspective, I don't understand how I would decide whether to show a multiple file picker or a directory picker. You display two buttons in the website UI, one for pick file and one for pick directory. We don't really have a choice as long as we live under the two constraints of: * Websites wants to do their own pick UI * OSs can't display pickers which allow picking either a file or a directory. I don't think I've ever seen a native application on any platform offer two buttons, one to pick one or more files, and one to pick one (or more?) directories. I think this should be a large red flag. Now if I'm wrong and this kind of UI is in fact a thing, then fair enough, but if it's not, maybe we should go and study how this problem is solved in native apps. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms: input type=file and directory tree picking
On Tue, Oct 1, 2013 at 3:44 PM, Ian Hickson i...@hixie.ch wrote: * Websites wants to do their own pick UI * OSs can't display pickers which allow picking either a file or a directory. I don't think I've ever seen a native application on any platform offer two buttons, one to pick one or more files, and one to pick one (or more?) directories. I think this should be a large red flag. Now if I'm wrong and this kind of UI is in fact a thing, then fair enough, but if it's not, maybe we should go and study how this problem is solved in native apps. I can't find any applications off-hand which allow both in the first place, but Windows doesn't have a dialog that can do both. Typically you end up with two separate buttons/menu items, but presented as separate features, eg.Open File and Import Directory. (Drag and drop doesn't need to make this distinction. I'm not sure what should happen if you have a files input, and drag a directory into it that you couldn't have selected with the file picker.) -- Glenn Maynard
Re: [whatwg] onclose events for MessagePort
On Tue, Oct 1, 2013 at 11:13 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/1/13 2:11 PM, Ian Hickson wrote: How often do we expect two tabs to be talking to each other though? Or a page to an out-of-process subframe? Or an out-of-process worker. I would think that in Chrome SharedWorkers can come from a separate process, though that might change if/when chrome switches to out-of-process iframes. / Jonas
[whatwg] Collecting tips for getting involved in web standards
I'm giving a talk in a couple days at LXJS, and part of it is to teach the attendees how standards work and how they can get involved. I'm putting together tips, based on my experiences over the last year or so, and was wondering if the members of these lists had anything they wanted to contribute. I'm collecting at https://gist.github.com/domenic/6787314. There's more text there, but in brief, so far I have: - Lurk first - Solution time is later - Understand the constraints - Concede defeat, and don't retread - Leave your sense of logic at the door To avoid noise on these lists, since admittedly this topic is not terribly related to solving actual problems in ECMAScript or to the WHATWG specs, we can have the discussion there, or you can reply to me directly.
