| 07:00 | <annevk> | TabAtkins: not sure if this is a problem, but when I updated WHATWG's bikeshed boilerplate for a change in new issue URLs, it was picked up automatically without me having to generate the manifest |
| 07:01 | <annevk> | TabAtkins: I have now updated the manifest as well, but that makes it seem redundant |
| 08:50 | <Noam Rosenthal> | Domenic: added https://github.com/whatwg/html/issues/9824 to track the event loop spec vs. impl differences. hoping to tackle it gradually |
| 08:53 | <Noam Rosenthal> | smaug: I think I said something misleading about fetchLater when we spoke about it a few days ago. It is reliable in the "renderer process is killed" scenario, as the whole logic is spec'ed to work in the network process (inside fetch, in spec terms). It's actually a main feature of fetchLater as opposed to sending beacons in pagehide. |
| 08:54 | <smaug> | ok, so whatever is representing a "network process" in each browser |
| 08:55 | <smaug> | OS can still kill those processes on mobile, no? |
| 08:59 | <Noam Rosenthal> | smaug: yes, but that's equivalent to killing the whole browser in a way. |
| 09:01 | <Noam Rosenthal> | our recommendation (it's also in the spec) is that if there are indication that the browser itself is about to lose execution rights or be killed (e.g. backgrounded on iOS) then flush those ASAP |
| 09:01 | <smaug> | depends on the browser. But yes. And the point is still that we are replacing one unreliable API with another one. The new one is likely less unreliable. |
| 09:03 | <Noam Rosenthal> | smaug: It's as reliable as calling fetch, which can also not happen if the network process gets killed |
| 09:03 | <smaug> | and browsers could have implemented also the old API in a more reliable way, but have chosen not to |
| 09:04 | <Noam Rosenthal> | they couldn't. because if the renderer process is killed, you wouldn't get JS execution and pagehide |
| 09:06 | <smaug> | I didn't say the old one would be as reliable. I said they could have implemented it in a more reliable way. |
| 09:06 | <Noam Rosenthal> | you'd need something like "you're about to lose execution rights or be killed, please fire this event" |
| 09:07 | <Noam Rosenthal> | That's not a feasible premise |
| 09:07 | <Noam Rosenthal> | I would say that fetchLater(url) is a practical alternative to something like firing pagehide as a kill signal... note that renderer processes that get killed might have already crashed or have a hanging main thread |
| 09:08 | <smaug> | I haven't said fetchLater is somehow bad API 🙂 |
| 09:08 | <Noam Rosenthal> | if your renderer process crashed/hang, fetchLater would still work while I don't see how we could make addEventListener('pagehide', () => fetch(...) work |
| 09:09 | <smaug> | But we need to always think what extra complexity we want to add to the platform |
| 09:10 | <smaug> | per the proposal, implementation could handle fetchLater asap a page is being unloaded or moved to bfcache, right? |
| 09:10 | <Noam Rosenthal> | yes |
| 09:10 | <Noam Rosenthal> | we try to leave a lot of room for simpler implementations |
| 09:22 | <smaug> | What about the page becoming a background page, I mean user switches tab (or whatever similar concepts mobile has)? Ah, looks like activationTimeout is just a hint |
| 09:23 | <smaug> | So UA could trigger fetchLater fetches immediately also in that case |
| 09:23 | <Noam Rosenthal> | smaug: yes, it's "please fetch this, no later than activationTimeout if posslbe" |
| 09:24 | <smaug> | I wonder if that property should have "hint" in its name, or perhaps deadline or some such, just to give the impression that it isn't by no means accurate |
| 09:24 | <Noam Rosenthal> | I'm fine with calling it deadline |
| 09:30 | <Noam Rosenthal> | (by "fine with" I mean I agree that it tells a more accurate story) |
| 09:32 | <smaug> | Noam Rosenthal: so there is no way to track which fetches have been processed? |
| 09:35 | <Noam Rosenthal> | smaug: sure, the return value of fetchLater has an activated boolean |
| 09:36 | <smaug> | how does that tell it? |
| 09:36 | <smaug> | oh, I see |
| 09:37 | <Noam Rosenthal> | yea when the fetch is activated the network process also posts a task on the document to flip the flag |
| 09:37 | <Noam Rosenthal> | ... if the document is still around |
| 11:02 | <annevk> | Jeffrey Yasskin: thanks, that indeed seems to work well! |
| 11:32 | <canadahonk> | Was MessageEvent.userActivation ever added to the HTML spec, afaict only the navigator interface was? (ref https://github.com/whatwg/html/pull/8254) |
| 11:34 | <annevk> | canadahonk: I don't think it was, nor was that proposal ever finalized afaik |
| 11:36 | <canadahonk> | What would be needed to get it in the spec? (Chrome has been shipping since 2018) |
| 11:43 | <annevk> | canadahonk: a specification with a design that has agreement? |
| 11:44 | <annevk> | canadahonk: I haven't looked at this recently, but I believe this feature has a repository with a number of outstanding issues |
| 11:44 | <canadahonk> | Yeah https://github.com/dtapuska/useractivation |
| 11:46 | <canadahonk> | fwiw I'll probably leave it as it doesn't look like it even has a positive consesus |
| 11:47 | <annevk> | canadahonk: yeah I think that proposal was superseded by https://github.com/WICG/capability-delegation but then they never completed that new one |
| 12:56 | <annevk> | smaug: when you say something isn't a "UI event", what do you mean by that? Not sure why scroll and resize are not it. Because they don't use UIEvent or some such? |
| 12:57 | <smaug> | Those aren't any sort of input events, triggered by the user |
| 12:57 | <smaug> | They are just plain normal Events, dispatched when either scrolling or resizing has happened |
| 12:58 | <annevk> | smaug: is that because there's some more fundamental event that ultimately caused the scrolling to happen, such as keyboard or mouse input? Would that make click not a UI event either? |
| 12:59 | <smaug> | Click isn't user input, no. |
| 12:59 | <smaug> | click is normally the "default action" after user has done mousedown and mouseup |
| 13:00 | <smaug> | click is synchronous |
| 13:01 | <annevk> | Right, I think we still want to define it in relation to those other events precisely because of that, but they might be simpler as they're more of a side effect |
| 13:02 | <smaug> | defining when mousedown and up fire would naturally define when click fires (assuming we think about pointer triggered click). Similarly to keyboard triggered click. |
| 13:03 | <smaug> | But the scheduling part is mostly about *down/*move/*up |
| 13:04 | <smaug> | Browsers have some scheduling for those, but it is still unclear what is the best in which situations |
| 13:09 | <smaug> | we could start by making rendering step its own task, given that all the browsers do that |
| 13:27 | <annevk> | Thanks, makes sense to me |
| 13:38 | <Noam Rosenthal> | I checked webkit code and it's not exactly a task there, in the EventLoop sense from what I could tell |
| 14:11 | <smaug> | ah. I based my comment on what was discussed during tpac |
| 14:18 | <Noam Rosenthal> | I could be wrong, my webkit foo is a bit out of date |
| 14:18 | <Noam Rosenthal> | but I would suggest to double check |
| 14:59 | <annevk> | I wouldn't focus too much on the exact code, only on observable differences. We need script to run in the context of a task as otherwise a number of things seem to break down, so we should move "update the rendering" to that model. That it also makes the event loop more readable is a nice bonus. |
| 15:50 | <TabAtkins> | TabAtkins: not sure if this is a problem, but when I updated WHATWG's bikeshed boilerplate for a change in new issue URLs, it was picked up automatically without me having to generate the manifest |
| 15:52 | <TabAtkins> | Oh tho, hm, it's been a while since I updated the built-in data; it predates the slight change to manifest format. I wonder if it's just noticing that the local manifest is borked and downloading everything (and the fact that the hash was wrong on the remote manifest didn't matter, so long as the file is in there). |
| 16:03 | <Noam Rosenthal> | annevk: curious what breaks by not having a current task apart from microtasks? |