| 03:12 | <mnot> | QQ - WHATWG is listed on the TPAC agenda -- is there an agenda? Is it likely to be well-attended? |
| 12:24 | <Noam Rosenthal> | smaug: question re. https://github.com/whatwg/html/issues/9315#issuecomment-1680504091 In Gecko, when there is a rAF pending, would that block the first paint when coming back from bfcache? |
| 12:25 | <smaug> | there shouldn't be rAF pending when coming out of bfcache |
| 12:26 | <Noam Rosenthal> | can't you call requestAnimationFrame in pagehide? |
| 12:26 | <smaug> | sure, but the current rendering might be cached |
| 12:27 | <smaug> | and shown to the user and then rAF called |
| 12:27 | <Noam Rosenthal> | ok, so it's sort of the same as what we're proposing with reveal |
| 12:28 | <smaug> | expect that reveal would force waiting for handling of reveal event before showing anything to the user |
| 12:28 | <Noam Rosenthal> | it's guaranteed to be called before the next rAF, and in the case of an actual view transition also guaranteed to be before the first paint - but that's because VT holds painting of the new document, not because of the reveal event itself |
| 12:28 | <Noam Rosenthal> | what forces waiting is the fact that there is a view transition, not the reveal event. |
| 12:29 | <Noam Rosenthal> | if there is a reveal event without a VT - show the cached image, fire the reveal event, fire the rAF callback if it exists, and continue your life |
| 12:30 | <smaug> | Isn't that quite confusing semantics? In some case reveal would fire when the page has been already revealed to the user and in some case before |
| 12:31 | <Noam Rosenthal> | we could also make it wait when there is a reveal event handler, to prevent a flashing effect, if e.g. you're showing a clock |
| 12:32 | <Noam Rosenthal> | how does pageshow work in that regard btw? doesn't it have the same confusing aspect? |
| 12:32 | <smaug> | Right. I'm just worried about the misuse of the event. Right now bfcache can be really fast, no need to wait for anything. |
| 12:32 | <smaug> | pageshow doesn't have |
| 12:32 | <smaug> | it has nothing to do with rendering |
| 12:36 | <smaug> | if reveal does not have anything to do with rendering (in case when view transitions aren't around), then it would be just a duplicate of pageshow. Which would be a bit weird. |
| 12:37 | <smaug> | Could we possible have an event specific to view transitions? (just a thought) |
| 12:37 | <smaug> | Since those anyhow slow down the process of coming out of bfcache or animate that. |
| 12:37 | <Noam Rosenthal> | The problem with an event specific to view transitions, is that it can be error prone in the sense that you might be expect a VT, but perhaps something in the old document prevented a VT from happening |
| 12:40 | <smaug> | don't you want then some notification that VT didn't happen? |
| 12:40 | <Noam Rosenthal> | what would that look like? wouldn't that be the same as a reveal event with a null VT? |
| 12:41 | <smaug> | maybe, but it would fire only if the page was trying to use vt or something |
| 12:43 | <Noam Rosenthal> | yea perhaps we could fire it only when the page has opted-in to view transitions and find a VT-specific name. let me think this over |
| 13:07 | <Noam Rosenthal> | smaug: though I still think that What we were proposing is something that matches |
| 13:08 | <smaug> | pageshow has nothing to do with rendering |
| 13:08 | <smaug> | it is just to tell that page came out of bfcache, or in case of initial page load, it replicates load event |
| 13:18 | <smaug> | pageshow predates anything like rAF for quite a few years. |
| 13:19 | <Noam Rosenthal> | regardless of their purpose, in the case of VT both pageshow and rAF callback would have a different behavior based on whether there is an actual VT or not, and unlike pageshow, rAF is very related to rendering |
| 13:21 | <smaug> | why would the behavior of pageshow change in case there is vt around? |
| 13:21 | <Noam Rosenthal> | as in, if you call rAF on pagehide, and then restore from BFCache, you might or might not see the previous frame again, based on whether you have a VT |
| 13:22 | <Noam Rosenthal> | same with pageshow. When there is a VT, the first frame always waits for the main thread, and the first task in the main thread is to fire pageshow |
| 13:23 | <Noam Rosenthal> | so VT: pageshow is before first frame, no VT: pageshow is potentially after cached first frame |
| 13:23 | <Noam Rosenthal> | reveal is not different |
| 13:23 | <Noam Rosenthal> | (or it could be, but then we risk misuse as you say) |
| 13:24 | <hsivonen> | I didn't write that test, so I'll try and reach out to the Googler that did and see if he can explain. |
| 13:28 | <Noam Rosenthal> | smaug: So I get why it's confusing, but it's also consistent with the existing rendering-related callback when restoring from BFCache, which is the first rAF. btw I believe this would be also consistent with ResizeObserver and IntersectionObserver callbacks (at least per spec), and they would also currently have this confusing behavior of sometimes being called after the previous frame, and they're rendering related. |
| 13:52 | <smaug> | Those just run when rendering updates happen. reveal on the other hand sounds like something which is bound to the first paint, and if it sometimes fires before and sometimes after paint, that is confusing. |
| 14:01 | <Noam Rosenthal> | you can say it's bound to the first paint of the new state of the document |
| 14:13 | <Noam Rosenthal> | smaug: we can call it beforerenderingupdate, maybe that would be less confusing? it would be guaranteed to be before we update the rendering, but perhaps not before first paint |
| 15:30 | <smaug> | that sounds like something which would happen before any rendering update |
| 15:43 | <Noam Rosenthal> | smaug: firstrender? firstanimationframe? firstrenderingupdate? Also I believe that the word reveal does kind of mean this in a way. You show an old state and you're about to reveal the new one. In the documentation we can be explicit that it means "before the rendering update after a navigation". |
| 17:04 | <Noam Rosenthal> | ... or readytorender, canrender. |
| 20:59 | <Dominic Farolino> | Np. So it looks like module scripts are appended to the "list of scripts that will execute when the document has finished parsing" here: https://html.spec.whatwg.org/multipage/scripting.html#script-processing-model:list-of-scripts-that-will-execute-when-the-document-has-finished-parsing, and that the blocking of executing scripts from that list based on style sheets is done here: https://html.spec.whatwg.org/multipage/parsing.html#stop-parsing:~:text=Spin%20the%20event%20loop%20until%20the%20first%20script%20in%20the%20list%20of%20scripts%20that%20will%20execute%20when%20the%20document%20has%20finished%20parsing%20has%20its%20ready%20to%20be%20parser%2Dexecuted%20set%20to%20true%20and%20the%20parser%27s%20Document%20has%20no%20style%20sheet%20that%20is%20blocking%20scripts |
| 20:59 | <Dominic Farolino> | hsivonen: Also relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=1622235 |