{"action":"created","issue":{"url":"https://api.github.com/repos/w3ctag/spec-reviews/issues/70","labels_url":"https://api.github.com/repos/w3ctag/spec-reviews/issues/70/labels{/name}","comments_url":"https://api.github.com/repos/w3ctag/spec-reviews/issues/70/comments","events_url":"https://api.github.com/repos/w3ctag/spec-reviews/issues/70/events","html_url":"https://github.com/w3ctag/spec-reviews/issues/70","id":105719690,"number":70,"title":"requestIdleCallback","user":{"login":"KenjiBaheux","id":6354698,"avatar_url":"https://avatars.githubusercontent.com/u/6354698?v=3","gravatar_id":"","url":"https://api.github.com/users/KenjiBaheux","html_url":"https://github.com/KenjiBaheux","followers_url":"https://api.github.com/users/KenjiBaheux/followers","following_url":"https://api.github.com/users/KenjiBaheux/following{/other_user}","gists_url":"https://api.github.com/users/KenjiBaheux/gists{/gist_id}","starred_url":"https://api.github.com/users/KenjiBaheux/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/KenjiBaheux/subscriptions","organizations_url":"https://api.github.com/users/KenjiBaheux/orgs","repos_url":"https://api.github.com/users/KenjiBaheux/repos","events_url":"https://api.github.com/users/KenjiBaheux/events{/privacy}","received_events_url":"https://api.github.com/users/KenjiBaheux/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/w3ctag/spec-reviews/labels/in%20progress","name":"in progress","color":"207de5"}],"state":"open","locked":false,"assignee":{"login":"dbaron","id":248721,"avatar_url":"https://avatars.githubusercontent.com/u/248721?v=3","gravatar_id":"","url":"https://api.github.com/users/dbaron","html_url":"https://github.com/dbaron","followers_url":"https://api.github.com/users/dbaron/followers","following_url":"https://api.github.com/users/dbaron/following{/other_user}","gists_url":"https://api.github.com/users/dbaron/gists{/gist_id}","starred_url":"https://api.github.com/users/dbaron/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dbaron/subscriptions","organizations_url":"https://api.github.com/users/dbaron/orgs","repos_url":"https://api.github.com/users/dbaron/repos","events_url":"https://api.github.com/users/dbaron/events{/privacy}","received_events_url":"https://api.github.com/users/dbaron/received_events","type":"User","site_admin":false},"milestone":{"url":"https://api.github.com/repos/w3ctag/spec-reviews/milestones/24","html_url":"https://github.com/w3ctag/spec-reviews/milestones/tag-telcon-2015-10-07","labels_url":"https://api.github.com/repos/w3ctag/spec-reviews/milestones/24/labels","id":1306451,"number":24,"title":"tag-telcon-2015-10-07","description":"","creator":{"login":"torgo","id":287526,"avatar_url":"https://avatars.githubusercontent.com/u/287526?v=3","gravatar_id":"","url":"https://api.github.com/users/torgo","html_url":"https://github.com/torgo","followers_url":"https://api.github.com/users/torgo/followers","following_url":"https://api.github.com/users/torgo/following{/other_user}","gists_url":"https://api.github.com/users/torgo/gists{/gist_id}","starred_url":"https://api.github.com/users/torgo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/torgo/subscriptions","organizations_url":"https://api.github.com/users/torgo/orgs","repos_url":"https://api.github.com/users/torgo/repos","events_url":"https://api.github.com/users/torgo/events{/privacy}","received_events_url":"https://api.github.com/users/torgo/received_events","type":"User","site_admin":false},"open_issues":2,"closed_issues":0,"state":"open","created_at":"2015-09-15T13:59:04Z","updated_at":"2015-10-07T22:42:36Z","due_on":"2015-10-07T04:00:00Z","closed_at":null},"comments":7,"created_at":"2015-09-10T02:18:00Z","updated_at":"2015-10-23T03:10:44Z","closed_at":null,"body":"There is a lot of interest from developers on this one and from what we learned by analyzing traces, a significant chunk of poor user experience issues could be resolved if it were available. We are eager to make this available, hence the request for a tag review.\r\n\r\ncc/ @rmcilroy\r\n\r\nSpec: https://w3c.github.io/requestidlecallback/\r\n\r\n - [outstanding issues](https://github.com/w3c/requestidlecallback/issues?q=is%3Aopen+is%3Aissue)\r\n - [Blink intent to implement](https://groups.google.com/a/chromium.org/d/msg/blink-dev/_0ZwVT4UFvU/wSa7HkmGz4QJ). Implementation status: behind the experimental flag in Chrome 47.\r\n - [chromestatus.com entry](https://www.chromestatus.com/feature/5572795866021888)"},"comment":{"url":"https://api.github.com/repos/w3ctag/spec-reviews/issues/comments/150440900","html_url":"https://github.com/w3ctag/spec-reviews/issues/70#issuecomment-150440900","issue_url":"https://api.github.com/repos/w3ctag/spec-reviews/issues/70","id":150440900,"user":{"login":"dbaron","id":248721,"avatar_url":"https://avatars.githubusercontent.com/u/248721?v=3","gravatar_id":"","url":"https://api.github.com/users/dbaron","html_url":"https://github.com/dbaron","followers_url":"https://api.github.com/users/dbaron/followers","following_url":"https://api.github.com/users/dbaron/following{/other_user}","gists_url":"https://api.github.com/users/dbaron/gists{/gist_id}","starred_url":"https://api.github.com/users/dbaron/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dbaron/subscriptions","organizations_url":"https://api.github.com/users/dbaron/orgs","repos_url":"https://api.github.com/users/dbaron/repos","events_url":"https://api.github.com/users/dbaron/events{/privacy}","received_events_url":"https://api.github.com/users/dbaron/received_events","type":"User","site_admin":false},"created_at":"2015-10-23T03:10:44Z","updated_at":"2015-10-23T03:10:44Z","body":"Re the discussion about defining the event loop:  there was some discussion in the Houdini task force meeting in Paris in August to write a specification that would define it better.  Minutes are at http://www.w3.org/mid/CADhPm3tC1CT=gBVqoq5TSfPXpnJoPPnxSrc7hEcYCr-X0Oi0Ow@mail.gmail.com although the summary at the top is not a particularly good summary of the key points from my perspective; better to read the full minutes.\n\n\nOn to further review of the spec:\n\n#### Larger issues\n\nI have two larger issues to raise (although I admit the first is somewhat vague):\n\n1. Does the spec's notion of \"idle\" scale well to a more multi-core future in which browsers do a good job of taking advantage of those cores?  In particular, engines may be moving to doing more tasks (e.g., beyond compositing to tasks that are more part of layout or even style computation) on other threads, or (probably less worrysome here) dividing a main-thread-blocking task across multiple threads to help it finish faster.  I tend to think the APIs are probably ok in that regard, given that they're a relatively straightforward extension of setTimeout, but I'm a little more worried about the prose (both the diagrams of how things work in section 2 and the processing model in section 5 -- see the next point).\n\n\n2. I'm worried the processing model is over-defined.  (This concern comes from bzbarsky, who I believe raised an issue on it; I think https://github.com/w3c/requestidlecallback/issues/28 although it might be any one of 25-29, and I don't have good enough internet access to check right now.)  For example, it defines the duration of an idle period at the start of that idle period (steps 4, 5, and 8 of the \"When the user agent wishes to start an event loop's idle period\" algorithm), and earlier says that no other idle period can begin before that deadline has passed (\"Let last_deadline be the last idle period deadline associated with the current event loop, or 0 if no previous deadline exists.\"; step 1 of the same algorithm), so essentially it forbids running any idle callback that wasn't posted before that deadline was determined until after the deadline.  This seems like it might lead to underutilization of perfectly-usable idle time; I'd rather implementations be allowed to use the idle time effectively by calling idle callbacks, using strategies that they deem best for speed, power usage, interactivity, etc.  (There might also be good reasons to want such usage, e.g., because it may be better to do a bunch of work together than to wait and cause additional CPU wakeups.)  That said, I'm not against all constraints in the processing model; a number of the other constraints (e.g., relating to the relative order of idle callbacks, or the fact that each idle callback is called from a separate queued task posted after the previous one finishes) seem good.  (This applies to both the normative description of the processing model in section 5 and to its non-normative description in section 2.)  For example, if an implementation ends an idle period whose deadline was initially 50ms long only 10ms into it because there was user input, but then finishes processing that input 10ms after that, the spec currently requires not starting another idle period for another 30ms.\n\n#### Detailed comments\n\nI also have a few more specific comments from reading the spec.\n\n##### 1. Introduction\n\nDo you really want to mention localStorage as an example, given that we'd like to discourage use of it (in favor of asynchronous storage APIs like IndexedDB)?\n\n\"can't make any assumptions\" should probably say something more like \"can't make accurate/good/??? assumptions\" (i.e., it can make assumptions -- they will just often be wrong)\n\n##### 2. Idle Periods\n\nFirst paragraph seems to imply that input processing is for a given frame, which seems a little fishy to me.  (Or maybe that's true in some browsers?)\n\n\"The user should be careful to account for\" doesn't mean the user of the browser (which is what we usually mean by \"user\"); it means the user of the API.\n\nThis says the callbacks are run in FIFO order, but it's really only FIFO for each document separately.  (Though maybe the inter-document order should be better-defined, and defined in a way that doesn't allow one document's idle callbacks to starve another document's, which seems possible in the current model?)\n\n\"Once an idle period is finished the user agent can schedule another idle period if it remains idle\" isn't strictly true per the processing model (given that the UA can't schedule another idle period until the previous one's deadline has passed), although I propose above that that be fixed.\n\n##### 4. Window interface extensions\n\nOne possible point of confusion:  when I first read through the IdleDeadline interface, I thought \"didTimeout\" was an attribute that reflected whether timeRemaining() was greater than 0 or not (although I was thinking that this should be a function rather than an attribute).  I wonder if developers might have the same confusion, and whether there's a better name available.\n\nUse of \"unsigned long\" indices is a little bit clunky, although I guess it's compatible with setTimeout.  One thing I worry about is that people might be converting code from setTimeout to requestIdleCallback (or using requestIdleCallback if available and falling back to setTimeout) -- so I wonder if it might help avoid hard-to-debug mistakes from that conversion if setTimeout and requestIdleCallback used the *same* space of integers rather than overlapping spaces (and maybe even if clearTimeout and clearIdleCallback were just the same underlying implementation, or maybe even not introducing a new clearing method).\n\n\"Wait until any invocations of this algorithm started before this one whose timeout is equal to or less than this one's have completed.\":  This seems like it might be a little bit underconstrained; it seems like it might be worth guaranteeing sorting by (requestIdleCallback time + timeout).\n\n##### 5. Processing model\n\n\"If the Document 's hidden attribute [page-visibility] is false\" seems like it should say true rather than false.\n"}}