| 04:47 | <Lorin> | Huh, apparently :scope doesn't work within DocumentFragment, seems kinda silly |
| 06:33 | <hsivonen> | Sam Sneddon [:gsnedders]: wpt.fyi says that https://github.com/web-platform-tests/wpt/blob/master/html/browsers/the-window-object/garbage-collection-and-browsing-contexts/discard_iframe_history_1.html passes only in Firefox, and when I try to align about:blank behavior with other browsers, the test starts behaving in Firefox the way it already behaves in Chrome. This strongly suggests we should change the test expectation, right? Do you recall if there's spec text to adjust as well? |
| 07:13 | <hsivonen> | Sam Sneddon [:gsnedders]: wpt.fyi says that https://github.com/web-platform-tests/wpt/blob/master/html/browsers/the-window-object/garbage-collection-and-browsing-contexts/discard_iframe_history_1.html passes only in Firefox, and when I try to align about:blank behavior with other browsers, the test starts behaving in Firefox the way it already behaves in Chrome. This strongly suggests we should change the test expectation, right? Do you recall if there's spec text to adjust as well? + 1 on this line: https://github.com/web-platform-tests/wpt/blob/master/html/browsers/the-window-object/garbage-collection-and-browsing-contexts/discard_iframe_history_1-1.html#L11 |
| 09:29 | <Domenic> | Yes, that line looks quite suspect... loading a no-src (i.e. about:blank) iframe should not increase history length according to both the current spec and the upcoming rewrite (https://github.com/whatwg/html/pull/6315) |
| 09:29 | <Domenic> | Oh, no, I misread, it's navigating... |
| 09:29 | <Domenic> | Oh, this is because of the load replace timing I am pretty sure |
| 09:30 | <Domenic> | https://github.com/web-platform-tests/wpt/commit/c1bb1fdaa510c14d31ca8307f4778b015a6bb30d |
| 09:30 | <Domenic> | https://github.com/whatwg/html/pull/6714 |
| 09:31 | <Domenic> | Well OK it's simpler than that, sorry. |
| 09:31 | <Domenic> | The src-less srcdoc-less iframe is on its initial about:blank |
| 09:32 | <Domenic> | Any navigation from the initial about:blank, per current and future spec, must be a replace navigation (does not increment history.length). |
| 09:34 | <Domenic> | This is the spec change: https://github.com/whatwg/html/pull/6595 and this is the tests PR that never landed!?!?! https://github.com/web-platform-tests/wpt/pull/28541 |
| 13:58 | <peterv> | Domenic: I'm looking at async iterable support in Firefox, the WebIDL spec talks about a "end of iteration value", but it doesn't actually define what that looks like? |
| 14:02 | <peterv> | Domenic: ah, I see, it's just an opaque value that then forces CreateIterResultObject(undefined, true), nevermind |
| 15:07 | <annevk> | Works here... |
| 16:55 | <Sam Sneddon [:gsnedders]> | Sam Sneddon [:gsnedders]: wpt.fyi says that https://github.com/web-platform-tests/wpt/blob/master/html/browsers/the-window-object/garbage-collection-and-browsing-contexts/discard_iframe_history_1.html passes only in Firefox, and when I try to align about:blank behavior with other browsers, the test starts behaving in Firefox the way it already behaves in Chrome. This strongly suggests we should change the test expectation, right? Do you recall if there's spec text to adjust as well? |
| 18:17 | <hsivonen> | I have no idea about tests jgraham (not pinging because OOO) wrote around a decade ago. |
| 18:19 | <Dominic Farolino> | dumb question: Is it not possible to add a click event handler on an iframe that fires when the user clicks in the iframe? |
| 18:19 | <Dominic Farolino> | The only way I can seem to invoke a click event handler on an iframe is via iframeElement.click() in script |
| 21:57 | <shu> | spec question about dedicated worker lifetimes: if dedicated worker A postMessage()s to dedicated worker B, can A die before B receives the message? if so, does the spec guarantee that B will receive the message? |
| 21:59 | <Andreu Botella (OOO till 5 Sept)> | It seems like actual engines don't keep dedicated workers alive after their parent dedicated worker dies, but the spec is not 100% clear about this: https://github.com/whatwg/html/issues/7840 |
| 22:01 | <Andreu Botella (OOO till 5 Sept)> | but going by the spec, and assuming that it was clear that dedicated worker B stays alive – postMessage() posts a task on B's event loop, so assuming that A dies after the postMessage call finishes, it can die before B receives it, but B will still receive it |
| 22:49 | <shu> | great, that's exactly what i was looking for, thanks |