{"action":"created","issue":{"url":"https://api.github.com/repos/whatwg/html/issues/3727","repository_url":"https://api.github.com/repos/whatwg/html","labels_url":"https://api.github.com/repos/whatwg/html/issues/3727/labels{/name}","comments_url":"https://api.github.com/repos/whatwg/html/issues/3727/comments","events_url":"https://api.github.com/repos/whatwg/html/issues/3727/events","html_url":"https://github.com/whatwg/html/issues/3727","id":327930204,"node_id":"MDU6SXNzdWUzMjc5MzAyMDQ=","number":3727,"title":"Adjust event loop processing model to allow asynchronous layout of frames","user":{"login":"chrishtr","id":3453258,"node_id":"MDQ6VXNlcjM0NTMyNTg=","avatar_url":"https://avatars3.githubusercontent.com/u/3453258?v=4","gravatar_id":"","url":"https://api.github.com/users/chrishtr","html_url":"https://github.com/chrishtr","followers_url":"https://api.github.com/users/chrishtr/followers","following_url":"https://api.github.com/users/chrishtr/following{/other_user}","gists_url":"https://api.github.com/users/chrishtr/gists{/gist_id}","starred_url":"https://api.github.com/users/chrishtr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chrishtr/subscriptions","organizations_url":"https://api.github.com/users/chrishtr/orgs","repos_url":"https://api.github.com/users/chrishtr/repos","events_url":"https://api.github.com/users/chrishtr/events{/privacy}","received_events_url":"https://api.github.com/users/chrishtr/received_events","type":"User","site_admin":false},"labels":[{"id":819116794,"node_id":"MDU6TGFiZWw4MTkxMTY3OTQ=","url":"https://api.github.com/repos/whatwg/html/labels/topic:%20event%20loop","name":"topic: event loop","color":"009800","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-05-30T23:07:12Z","updated_at":"2018-05-31T07:51:09Z","closed_at":null,"author_association":"NONE","body":"Currently, the event loop processing model [1] does not make reference to the concept of\r\ncomputing style or layout. It is assumed that updates to the DOM are atomic, and it\r\nis an implementation detail whether browsers update style or layout at a later time. This\r\nis true even for cases with multiple documents (frames), meaning that style and layout\r\nare updated atomically for all frames, at least as far as script can observe.\r\n\r\nIn practice, all browsers update style and layout during rendering frame generation, which\r\nis basically the same as step 3 from [1], \"update the rendering\". They do this because it\r\nis more efficient to update style and layout lazily than eagerly, in the presence of script\r\nwhich may make a sequence of style- and layout-inducing DOM mutations in one synchronous\r\nblock.\r\n\r\nFurther, Chromium in particular also updates all frames' style and layout at the same time\r\n(except when cross-domain iframes are \"throttled\", which concept is referenced in step 7.4 of [1]).\r\nHowever, even in this situation, Chromium will perform a synchronous style or layout if script references\r\nstyle- or layout-inducing CSS properties on DOM objects, so from the script point of view,\r\nstyle and layout for such frames are still atomic w.r.t. the main frame. (*)\r\n\r\nThe assumption of atomicity starts to break down with the desire to implement cross-domain\r\niframes in separate processes (Chrome calls this feature Site Isolation [4]), which is\r\nnecessary for security and desired for performance.\r\n\r\nTo avoid unreasonable implementation difficulty and poor performance in this multi-process scenario,\r\nit is necessary to decouple style/layout update of each frame from other frames. This means that in\r\ncases where one frame's size depends on the style or layout of another frame, we do not\r\nnecessarily force them to update in lockstep. Consider this example:\r\n\r\na.com frame:\r\n```\r\n\r\nvar f = document.querySelector(‘iframe’);\r\nf.width = 123;\r\nf.clientWindow.postMessage(“foo”, ”b.com”);\r\n```\r\n\r\n\r\nb.com sub-frame:\r\n```\r\nonmessage = () => {\r\n  console.log(\r\n      document.body.clientWidth);\r\n};\r\n```\r\n\r\nIn this code, b may observe a width that is not 123, until such time as a.com decides to render and then send a message to b.com's rendering process to update its layout.\r\n\r\nAn edit to the event processing model could be made, perhaps as follows:\r\n* Expand 7.12 to specify the concept of style-and-layout, expanding on what ResizeObserver suggests [2]\r\n* Specify that Documents which are not same-origin do not necessarily run on the same browsing context event loop task. Still require that the task which runs for a parent Document occurs earlier than that for a child Document.\r\n\r\nThe specification for behavior of methods like clientWidth or offsetWidth is part of the CSSOM spec,\r\nbut also needs to be edited to make clear that in the presence of multiple Documents, they are not\r\nnecessarily updated atomically.\r\n\r\n[1] https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model\r\n[2] https://wicg.github.io/ResizeObserver/#html-event-loop\r\n[3] https://drafts.csswg.org/cssom-view/\r\n[4] http://www.chromium.org/Home/chromium-security/site-isolation\r\n\r\n(*) With the above spec change, Chrome's behavior could be changed to avoid synchronous style-and-layout in this case also."},"comment":{"url":"https://api.github.com/repos/whatwg/html/issues/comments/393442625","html_url":"https://github.com/whatwg/html/issues/3727#issuecomment-393442625","issue_url":"https://api.github.com/repos/whatwg/html/issues/3727","id":393442625,"node_id":"MDEyOklzc3VlQ29tbWVudDM5MzQ0MjYyNQ==","user":{"login":"annevk","id":1544111,"node_id":"MDQ6VXNlcjE1NDQxMTE=","avatar_url":"https://avatars0.githubusercontent.com/u/1544111?v=4","gravatar_id":"","url":"https://api.github.com/users/annevk","html_url":"https://github.com/annevk","followers_url":"https://api.github.com/users/annevk/followers","following_url":"https://api.github.com/users/annevk/following{/other_user}","gists_url":"https://api.github.com/users/annevk/gists{/gist_id}","starred_url":"https://api.github.com/users/annevk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/annevk/subscriptions","organizations_url":"https://api.github.com/users/annevk/orgs","repos_url":"https://api.github.com/users/annevk/repos","events_url":"https://api.github.com/users/annevk/events{/privacy}","received_events_url":"https://api.github.com/users/annevk/received_events","type":"User","site_admin":false},"created_at":"2018-05-31T07:51:09Z","updated_at":"2018-05-31T07:51:09Z","author_association":"MEMBER","body":"See also #3497 and #3506. We should probably start tracking all issues that fall out of out-of-process similar-origin window agents in some way.\r\n\r\nWe need a big revamp of the standard that clearly allocates similar-origin window agents (to which the event loop will have to belong), allocates windows within those, and documents within those, and makes them play well with browsing contexts and such. And then we need to change the `WindowProxy` and `Location` object setup such that they're no longer 1:1 with windows, but end up acting as proper proxies with message passing. Once we have that it'd be much easier to define a reasonable scheduling of all these things.\r\n\r\nUnfortunately this kind of revamping is extremely tough and I haven't really been able to make a dent thus far.\r\n\r\ncc @bzbarsky "}}
{"actor":{"display_login":"annevk"}}