| 08:26 | <annevk> | Dominic Farolino: maybe it should say "ought to be handled" 🙂 |
| 11:18 | <smaug> | does wpt have some way to close alert() and similar popups? |
| 11:18 | <smaug> | jgraham: ^ |
| 11:35 | <jgraham> | smaug: Not in the middle of the test at present, but we attempt to close them at the end of the test in gecko. We could easily expose https://w3c.github.io/webdriver/#dismiss-alert for the "I know the test is supposed to have created an alert at this point" case. |
| 11:36 | <smaug> | ok. I was thinking to write some test for beforeunload, but perhaps I'll use mochitest for now |
| 11:39 | <jgraham> | smaug: If those WebDriver primitives are enough for your use case it's literally only boilerplate code to expose them. I could make a patch against wpt in gecko right away for you to experiment with. |
| 11:41 | <smaug> | https://w3c.github.io/webdriver/#user-prompts talks about alert/confirm/prompt, and about implicitly closing beforeunload prompt |
| 11:41 | <smaug> | I think I'd prefer to explicitly close beforeunload |
| 11:42 | <jgraham> | Ah, OK. It might be true that WebDriver by default interferes with beforeUnload, although I think it's only implicitly dismissed if you try to navigate when the prompt is present |
| 13:44 | <jgraham> | smaug: Hmm, so I tried it and the interaction with alert and the event loop, coupled with the limitations of WebDriver makes the implementation of accept_alert in wpt harder than I'd imagined. I might file this under "good candidate for a post-WebDriver-BiDi world" |
| 13:46 | <smaug> | ok |
| 13:46 | <jgraham> | Or, maybe I can make it work with the uuid-in-the-URL approach to identifying windows that's part of the channels works that's been stuck in review for a long time :/ |
| 13:46 | <jgraham> | But still, not going to do that today :) |
| 14:13 | <Nic Jansma> | Hi all! Nic Jansma from Akamai here. Had a quick question about our akamai-whatwg Github org (https://github.com/akamai-whatwg) Are "paid" organizations still required to be in the participants list (https://github.com/whatwg/participant-data/blob/main/entities.json#L366), or can we be in the Free plan? |
| 14:18 | <annevk> | Nic Jansma: it doesn't matter to the WHATWG what kind of GitHub organization your organization uses, as long as it has the ability for individuals belonging to your organization to publicize their membership |
| 14:19 | <annevk> | Hope that's not too ambiguous 🙂 |
| 14:20 | <annevk> | Nic Jansma: we do need a GitHub organization listed there, though |
| 14:23 | <Nic Jansma> | Yep! I'm planning on opening a PR for entities.json since the Contact info isn't up to date for Akamai right now. Ok, I think that answers my question about the Organization requirements. Thanks! Thanks annevk |
| 14:23 | <annevk> | Nic Jansma: sounds good, thanks for keeping it up-to-date! |
| 15:03 | <Domenic> | smaug: If those WebDriver primitives are enough for your use case it's literally only boilerplate code to expose them. I could make a patch against wpt in gecko right away for you to experiment with. |
| 15:11 | <jgraham> | Right, hence "against wpt in gecko" |
| 15:12 | <jgraham> | Obviously there would still have to be an RFC to actually land it, but in this case I think it would have been relatively uncontroversial since it's just exposing WebDriver functionality directly. |
| 15:15 | <jgraham> | The RFC process tends to be more of a burden when there's more substantive API design, or third party dependencies being added, or anything else that might affect the ability to run the tests in different environments. |
| 15:24 | <jgraham> | Speaking of RFCs, ping on https://github.com/web-platform-tests/rfcs/pull/98 |
| 16:44 | <Dominic Farolino> | OK so the note in the fetch spec is wrong then, and these URLs are not explicitly handled anywhere in HTML's navigation |
| 16:44 | <Dominic Farolino> | (whoops that was in response to andreu -- my client hadn't updated and I saw no messages in between :) ) |
| 19:34 | <Josh C> | Hi, is this a good place to ask about the unification of dropped directories/files and directory/file picker? my research has found the "entries" api and the "file system handle" api and i just want to know what i should be looking forward to. in short, what's gonna happen with these two specs? https://wicg.github.io/entries-api/ https://wicg.github.io/file-system-access/ |
| 20:17 | <wanderview> | I asked someone who is not in this chat and they responded: "entries-api is implemented by all browsers today, while non-chromium browsers haven't shown any interest in implementing those parts of the file system access API..." |
| 20:18 | <wanderview> | so it sounds like both specs will probably be around for a while |
| 20:24 | <Josh C> | thanks for the response, kind of a bummer i guess, but it does seem like the file system access stuff is a superset |
| 20:24 | <Josh C> | ¯\_(ツ)_/¯ |
| 22:10 | <sideshowbarker> | Josh C: to further complicate things: https://github.com/whatwg/sg/issues/176 |
| 22:11 | <sideshowbarker> | In a TPAC 2021 breakout session we discussed standardizing OPFS + AccessHandle: docs.google.com/document/d/1RBK5pshKiKWa0drPEPrYwsAmZUELO_23hGM2iJTFiJA/edit. It's essentially a new storage API like IndexedDB, but with a file system API. The infrastructure it provides will be so it can also be used to support native file system access, but that will not be part of this standard and as such cannot be mandated from implementations. |