2021-11-01 [17:10:24.0486] As far as what’s documented in MDN: ``` $ rg --no-line-number --no-filename 'spec_url": ".+whatwg.org' ~/workspace/mdn/browser-compat-data/http/headers/ | awk NF | cut -d ":" -f2- | sort "https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header", "https://fetch.spec.whatwg.org/#http-access-control-allow-credentials", "https://fetch.spec.whatwg.org/#http-access-control-allow-headers", "https://fetch.spec.whatwg.org/#http-access-control-allow-methods", "https://fetch.spec.whatwg.org/#http-access-control-allow-origin", "https://fetch.spec.whatwg.org/#http-access-control-expose-headers", "https://fetch.spec.whatwg.org/#http-access-control-max-age", "https://fetch.spec.whatwg.org/#http-access-control-request-headers", "https://fetch.spec.whatwg.org/#http-access-control-request-method", "https://fetch.spec.whatwg.org/#x-content-type-options-header", "https://fullscreen.spec.whatwg.org/#permissions-policy-integration", "https://html.spec.whatwg.org/multipage/infrastructure.html#autoplay-feature", "https://html.spec.whatwg.org/multipage/infrastructure.html#document-domain-feature", "https://html.spec.whatwg.org/multipage/origin.html#coep", "https://html.spec.whatwg.org/multipage/origin.html#the-headers", ``` … so from that, yeah, only Fetch and HTML (the Fullscreen one isn’t introducing any header) [17:11:31.0385] > <@annevk:mozilla.org> Apart from Fetch and HTML, do we have other WHATWG standards that introduce their own HTTP headers? * As far as what’s documented in MDN: ``` $ rg --no-line-number --no-filename 'spec_url": ".+whatwg.org' ~/workspace/mdn/browser-compat-data/http/headers/ | awk NF | cut -d ":" -f2- | sort "https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header", "https://fetch.spec.whatwg.org/#http-access-control-allow-credentials", "https://fetch.spec.whatwg.org/#http-access-control-allow-headers", "https://fetch.spec.whatwg.org/#http-access-control-allow-methods", "https://fetch.spec.whatwg.org/#http-access-control-allow-origin", "https://fetch.spec.whatwg.org/#http-access-control-expose-headers", "https://fetch.spec.whatwg.org/#http-access-control-max-age", "https://fetch.spec.whatwg.org/#http-access-control-request-headers", "https://fetch.spec.whatwg.org/#http-access-control-request-method", "https://fetch.spec.whatwg.org/#x-content-type-options-header", "https://fullscreen.spec.whatwg.org/#permissions-policy-integration", "https://html.spec.whatwg.org/multipage/infrastructure.html#autoplay-feature", "https://html.spec.whatwg.org/multipage/infrastructure.html#document-domain-feature", "https://html.spec.whatwg.org/multipage/origin.html#coep", "https://html.spec.whatwg.org/multipage/origin.html#the-headers", ``` … so from that, yeah, only Fetch and HTML (the Fullscreen one isn’t introducing any header) 2021-11-02 [19:37:48.0724] annevk: FYI my _“Show HTTP status code in CORS messages”_ patch landed in the WebKit sources https://trac.webkit.org/changeset/285145/webkit [19:41:37.0031] so that’ll soon be in a Safari TP release — and then I guess in Safari 15.x in March or April [23:35:13.0693] congrats! was somewhat expecting to see these error messages localized but no browser vendor does error messages correctly, so not surprised if that's the case. might need to make an account over now that you mention it [23:36:07.0825] they are localized in some browsers at least [23:39:31.0917] there are ways to localize error messages, but that doesn't seem to have happened in that changelog -- maybe they go back over it later? doubt it, but have seen great localization for error messages maybe twice [23:42:11.0041] the two software projects were Git and TypeScript believe it or not [03:37:24.0922] why are some tentative openUI tests being mixed with html tests? [03:55:23.0854] smaug: the intention might be to upstream the feature to HTML? [03:56:10.0886] I couldn't find any spec-like text for selectmenu [03:56:24.0037] perhaps I looked at from wrong places [03:56:52.0368] smaug: are they marked as tentative at least? [03:56:58.0934] sure [03:58:36.0929] seeing "the-selectmenu-element" here https://github.com/web-platform-tests/wpt/tree/ca3635d2be104d885837442cc5e7ada030d66b22/html/semantics/forms is a bit surprising. [05:03:39.0423] They're all marked `.tentative` [05:03:51.0850] Maybe they didn't know you could do that to a complete directory too [06:00:59.0368] annevk, Jake Archibald: I was thinking re. the controller thingy (https://github.com/whatwg/fetch/pull/1329), maybe instead of returning a struct that fetch exported functions for, to return a struct with algorithm fields, that are set before returning the controller, kind of like how the different algorithms are kept in fetch params). This way both fetch-params and the state are truly private, and the only thing returned/exported is terminate/abort/finalize or whatever method is operable after the fetch has started. WDYT? [06:03:26.0453] Noam Rosenthal: I think algorithm fields are for cases where the algorithm is _set_ by some other spec, but annevk will know more [06:05:09.0581] Yeah, generally concepts are "plain" structs and algorithms get everything they need passed as parameters [06:05:22.0694] ... Trying to prevent a situation where by putting the state information inside controller we make it "public", while what we want to publicize is only some methods to manipulate the fetch. [06:05:38.0665] * ... Trying to prevent a situation where by putting the state information inside controller we make it "public", while what we want to publicize is only some methods to manipulate the fetch. [06:05:48.0608] Can't the controller just have the public data? [06:05:52.0898] I think exposing the state of the fetch is reasonable [06:06:00.0950] fetch params can have the private data [06:06:10.0176] Assuming that we're talking about "ongoing" vs terminated [06:06:21.0541] so it exposes state, and later cacheState and timing info [06:06:31.0985] ... which are needed when finalizing [06:06:57.0453] Yeah, but we'd only set those on the controller when they are meant to become public (so we might duplicate them there, essentially) [06:07:26.0817] I guess cacheState can only be set before fetch finale, right? [06:07:32.0069] which would make this sort of work [06:07:41.0646] As in, we'd write to those fields on "fetch params", and then at some point copy the whole lot over to the controller [06:08:23.0107] yea, fetch finale would probably be where this happens, as that's where it's currently copied to the response [06:09:00.0969] So we'll end up with some duplication, but it also clarifies things in a way [06:09:06.0024] OK this makes more sense to me. Thanks! [06:09:13.0553] \o/ [06:09:26.0451] (Done with bikesheeding about this corner, going back to work) [06:09:40.0837] * (Done with bikesheeding about this corner, going back to work) [06:11:11.0321] I wish I had more painted bikesheds to show for it, but I guess that's why it's called that way [06:36:41.0706] Jake Archibald, annevk : followed your suggestion (https://github.com/whatwg/fetch/pull/1329), hope it's on the right track :) [06:57:26.0401] Noam Rosenthal: I haven't had a chance yet, but one thing we need to figure out is the interaction of this with service workers [06:57:42.0778] Noam Rosenthal: I just realized that while writing https://github.com/whatwg/fetch/pull/1343#issuecomment-957631425 [06:58:15.0988] Noam Rosenthal: service workers observe the termination for some things so they might need access to the controller or the state or some such [06:58:36.0457] Jake Archibald: did you consider that already perhaps? [07:12:43.0332] annevk: service worker is hand-waving this in a couple of places, so yeah, it's be great to switch this to an "abort when" based on some state [07:31:27.0838] > <@annevk:mozilla.org> Noam Rosenthal: I haven't had a chance yet, but one thing we need to figure out is the interaction of this with service workers I will get more acquainted with this [08:20:58.0888] Noam Rosenthal: cool! I think we need to expose the controller, essentially; I guess we only need to read state from it [08:21:36.0271] Noam Rosenthal: I'm not sure if that means we should stuff the controller on the request or just add an argument to "handle fetch", I guess the latter would be better [08:21:55.0573] Anyway, this is a bit off the cuff [08:48:29.0364] Domenic: In the streams spec, in `ReadableStreamPipeTo`, the spec says: > If source.[[controller]] implements ReadableByteStreamController, let reader be either ! AcquireReadableStreamBYOBReader(source) or ! AcquireReadableStreamDefaultReader(source), at the user agent’s discretion. (since the beginning of time: https://github.com/whatwg/streams/pull/512). What does this mean? In what cases should the user agent use which reader type? I can't find any docs in surrounding code snippets. [08:48:35.0315] * Domenic: In the streams spec, in `ReadableStreamPipeTo`, the spec says: > If source.[[controller]] implements ReadableByteStreamController, let reader be either ! AcquireReadableStreamBYOBReader(source) or ! AcquireReadableStreamDefaultReader(source), at the user agent’s discretion. (since the beginning of time: https://github.com/whatwg/streams/pull/512). What does this mean? In what cases should the user agent use which reader type? I can't find any docs in surrounding code snippets. [09:08:35.0954] Luca Casonato: this is basically saying that the choice of reader is unobservable, so if you want to use a byte reader because you think you can do smart byte thingies with it while piping, go ahead [09:08:52.0942] ah, ok [09:09:24.0542] thx [09:16:00.0230] sefeng: hey welcome! https://github.com/whatwg/html/pull/7285 could use your review I think. And potentially that of emilio. [09:16:44.0467] roger, will do [09:50:35.0702] Domenic: if `x in y` is false, will `y[x]` always be undefined? [09:50:56.0351] /me wonders whether to merge https://github.com/web-platform-tests/wpt/pull/31461 [09:52:26.0766] > <@annevk:mozilla.org> Domenic: if `x in y` is false, will `y[x]` always be undefined? No (because Proxy) [09:53:11.0042] Luca Casonato: fair, but that doesn't seem applicable here [09:53:21.0779] Oh ok, then idk [09:57:07.0663] Seems fine [09:58:58.0892] > <@noamr:matrix.org> Jake Archibald, annevk : followed your suggestion (https://github.com/whatwg/fetch/pull/1329), hope it's on the right track :) really nice! [10:51:56.0392] > <@annevk:mozilla.org> Noam Rosenthal: I'm not sure if that means we should stuff the controller on the request or just add an argument to "handle fetch", I guess the latter would be better Definitely the latter. Seems natural to me that SW would get a "fetch controller" as a parameter and would be able to query if it is terminated [10:54:33.0164] I would try to avoid associating more things with requests/responses, as those are transient serializable beings and when we associate "procedural" beings like fetch controller (or "an ongoing fetch") we make them confusing... (does this controller gets serialized or stored with the request? how?) that's what happened with associating timing info to a response, where it got ambiguous in terms of caching and SW [10:55:15.0396] adding a parameter to SW's fetch "handle fetch" is a clean solution to this problem [11:14:45.0117] annevk, Jake Archibald I think one thing that makes SW's "handle fetch" a bit different is that it asynchronously returns a response, rather than receive a `processResponse` callback algorithm or so. If we'd change it to be the latter, the SW fetch could return its own controller and the main fetch could terminate it, rather than invert it to where SW has to check whether its caller ("the fetch instance") was terminated. [11:19:32.0817] I wonder what happens today if the abort happens after the service worker returned a response. Does the service worker still get notified? Perhaps that's just a state check on the service worker side though... [11:20:06.0881] Making that interaction with the service worker non-blocking sounds reasonable, though I'm not entirely sure I see what it would buy us quite yet. [11:22:23.0515] I guess having a controller for the fetch event would give an opportunity to not forward signals when it's too late anyway, but realistically you'd have to implement that check on the receiver side as well. [11:23:28.0129] I should have time to give all this another look at tomorrow [14:53:57.0863] annevk: looks like removing "pair" broke Web IDL: https://github.com/whatwg/webidl/runs/4082229137?check_suite_focus=true [15:16:26.0659] Kagami is on it 2021-11-03 [23:17:08.0422] Thanks krosylight! [01:10:43.0300] /me denies everything [02:38:21.0859] Jake Archibald: so one thing that strikes me is that there's no forwarding of cancelation to a fetch initiated by the service worker [02:39:13.0135] annevk: in which direction? As in, which side is listening for the cancelation, and which side is cancelling? [02:39:18.0664] Jake Archibald: so if a document fetches A and the service worker fetches B and returns that, when exactly will it listen to aborting of A? [02:40:31.0063] annevk: if the stream is cancelled, that part works right? For stuff that happens before that, I thought `fetchEvent.request.signal` could be used as an indicator [02:40:39.0155] I guess only if it reuses the Request object in some manner, although I'm not sure how well that is defined [02:41:20.0635] I think it there might be some race issues, but canceling the stream probably works, yeah [02:43:00.0692] Noam Rosenthal: I think one thing that might influence the design of the interaction with service workers is what we want to do with timing [02:43:15.0579] Noam Rosenthal: I'm not entirely sure what information needs to be exchanged [02:43:42.0879] Noam Rosenthal: if that information would ideally be on a "service worker fetch event controller", I guess that's what we should add [02:44:15.0284] Noam Rosenthal: as per your suggestion, and fetch would forward an abort to that controller [02:45:35.0322] (It's a little weird that in JavaScript the cancelation is managed by AbortSignal on the Request, but that doesn't encompass all types of aborting that might happen, so maybe this is okay.) [02:54:43.0751] annevk: regarding timing, going forward there shouldn't be interaction. It's part of why I want to make things more explicit there [02:55:31.0035] *only* a fetch would keep its timing info and report it. later of course we can add more things to the controller. [02:56:05.0175] (the service worker timing is only relevant to navigation timing, and in that case the timing is not part of a fetch but is queried directly from the service worker) [02:56:53.0769] Noam Rosenthal: oh, I thought we also needed to expose Cache API timing and things like that [02:57:24.0295] for the fetch, we need to expose "finalize and report timing info" [02:57:41.0914] cache state can be read from the response [02:57:50.0498] there's nothing new we need to expose from service worker [02:58:25.0469] Noam Rosenthal: so that means that if there is service worker the timing information ends up being mostly opaque, right? [02:58:36.0158] it's reported inside the service worker [02:58:47.0799] so you can do `performance.getEntries` from within service worker code etc [02:58:59.0441] but it's opaque to the caller fetch [02:59:42.0087] it felt like exposing that information twice mainly creates ambiguities [03:00:27.0043] ... that's why I didn't want that information on `response` which is a strange object that gets passed around and stored [03:00:43.0195] thanks, sgtm [03:01:10.0671] I added a very brief summary of our options for service workers to your PR [03:06:25.0627] what's "UB territory"? :) [03:13:21.0062] UB being undefined behavior [03:13:44.0023] AH, TIL [07:04:52.0330] Luca Casonato: fwiw, the cookie thing is blocked on getting someone from Chrome or Safari to chime in; hopefully it's clear from the prose and tests that it's not a whole lot of additional work [07:05:45.0776] Luca Casonato: I have a couple more nits on the PR, but might as well wait until we have the higher-level checkboxes done [07:06:14.0269] (And I'm also willing to push a fixup for that myself in due course) [10:39:59.0224] > <@annevk:mozilla.org> Luca Casonato: fwiw, the cookie thing is blocked on getting someone from Chrome or Safari to chime in; hopefully it's clear from the prose and tests that it's not a whole lot of additional work link? [10:41:11.0285] hober: heya, https://github.com/whatwg/fetch/pull/1346 [16:41:40.0795] I just opened https://webidl.spec.whatwg.org/ for the first time, and I definitely miss the table-of-contents-on-the-side from the old stylesheet. 2021-11-04 [18:41:30.0680] there was a dark mode too [21:10:42.0203] Hi folks, had some good successes using the WebIDL bindings to implement bindings between mruby and browser APIs. The `@webref/idl` package made this especially easy, thanks for providing that. While generating bindings works well, it feels like there are some fairly severe issues with this approach for a dynamic language. My current generated bindings are 800kb, which is non-trivial for a webapp, especially on top of the mruby interpreter and emscripten runtime. This isn't too bad with caching but will still be a show-stopper for many users. I was wondering if there's ever been any interest in providing a JavaScript API that can be used to load Web IDL bindings directly from the browser at runtime. This would allow dynamic languages to lazily bind to Web APIs as necessary, saving on the need to send and process all bindings upfront. [21:12:21.0668] As it stands, I think I'll have to opt to create bindings for JavaScript objects at runtime based on reflection (or just depressing `method_missing` hacks), which is a shame since I do really like having classes generated with all the proper metadata. [21:13:27.0569] * Hi folks, had some good successes using the WebIDL bindings to implement bindings between mruby and browser APIs. The `@webref/idl` package made this especially easy, thanks for providing that. While generating bindings works well, it feels like there are some fairly severe issues with this approach for a dynamic language. My current generated bindings are 800kb, which is non-trivial for a webapp, especially on top of the mruby interpreter and emscripten runtime. This isn't too bad with caching but will still be a show-stopper for many users. I was wondering if there's ever been any interest in providing a JavaScript API that can be used to load Web IDL bindings directly from the browser at runtime. This would allow dynamic languages to lazily bind to Web APIs as necessary, saving on the need to send and process all bindings upfront. [21:18:03.0592] * Hi folks, had some good successes using the Web IDL standard to implement bindings between mruby and browser APIs. The `@webref/idl` package made this especially easy, thanks for providing that. While generating bindings works well, it feels like there are some fairly severe issues with this approach for a dynamic language. My current generated bindings are 800kb, which is non-trivial for a webapp, especially on top of the mruby interpreter and emscripten runtime. This isn't too bad with caching but will still be a show-stopper for many users. I was wondering if there's ever been any interest in providing a JavaScript API that can be used to load Web IDL bindings directly from the browser at runtime. This would allow dynamic languages to lazily bind to Web APIs as necessary, saving on the need to send and process all bindings upfront. [00:32:01.0202] Jeffrey Yasskin: TabAtkins mentioned he might do something about it, I don't have the bandwidth at the moment [08:37:44.0134] yes, it's on my plate, tho i'm rather busy this month [08:38:17.0522] but generally i want to adapt the current w3c layout to whatwg, plus darkmode [14:07:24.0121] annevk: I was mumbling to krosylight how rarely I write spec prs and how I always need to go through all the documentation scattered in random places before writing the pr (well, first I need to always find the documentation). It would be really nice to have some step-by-step documentation for all the normal tooling around spec writing. [14:07:45.0699] I wonder if you or Domenic had time to write something down. [14:14:05.0466] There are https://respec.org/docs/ and https://tabatkins.github.io/bikeshed/ but maybe it's not easy enough to find them 2021-11-05 [23:17:35.0325] Cool! As long as there's some WHATWG green and orangered in there I'm happy 😊 [23:19:20.0930] smaug: generally for WHATWG specs it should all be linked from the README [23:20:40.0181] smaug: if there's things missing there or https://github.com/whatwg/meta/blob/main/CONTRIBUTING.md (which should be linked from all our READMEs) that would be good to know; probably best to file an issue against whatwg/meta [23:20:55.0505] * smaug: if there's things missing there or https://github.com/whatwg/meta/blob/main/CONTRIBUTING.md (which should be linked from all our READMEs) that would be good to know; probably best to file an issue against whatwg/meta [03:33:55.0080] annevk: I've been hoping to have some simple step-by-step instructions. If I start from the spec, I get to https://github.com/whatwg/html, which links to https://github.com/whatwg/html/blob/main/CONTRIBUTING.md which links to https://github.com/whatwg/meta/blob/main/CONTRIBUTING.md . then one goes back to previous page which says something about wattsi (but doesn't tell whether that should be installed, but kind of hints about it), and then there is a link to https://github.com/whatwg/html-build. oh, and I forgot a link to https://github.com/whatwg/meta/blob/main/COMMITTING.md was also mentioned somewhere [03:34:13.0269] So the information is in various places and not in any clear order [03:38:53.0948] smaug: that's fair; though it's also tricky to find the right balance there since the most basic thing is "create a branch", "edit a file", "commit", "create a PR" [03:40:05.0726] Since I live mostly in mozilla-central, I've got used to so simple build + "pr creation" setup with ./mach and moz-phab 😉 [03:40:22.0850] And generally build tools beyond make are optional, there's a service for all of them (or you can just create PRs and see if things work) [03:41:12.0943] smaug: right yeah, git/GitHub knowledge is assumed at the moment... I'm using GitHub Desktop myself for some of the actions and it's quite nice if you don't mind a GUI [03:43:45.0791] I wasn't thinking to include all the github instructions, although some common practices might not be a bad idea, if there are things which happen to fit into spec writing process particularly well [03:48:22.0405] Perhaps a "Your first PR" list of steps that's linked prominently from each README? (With HTML perhaps having its own list of steps for reasons.) [03:53:35.0980] Something like that would be great, at least for me, since all my spec prs are basically the first ones, given how rarely I do them. [04:03:43.0650] smaug: I filed https://github.com/whatwg/meta/issues/232 as a start [04:04:05.0431] thanks! [07:22:46.0498] > <@annevk:mozilla.org> Cool! As long as there's some WHATWG green and orangered in there I'm happy 😊 Honestly I've never been so sure about the orangered :) [07:33:03.0818] So apparently Chromium's UTF-16 decoder skips the replacement character for truncated sequences on fetches (that is, for page loads and XHR, but not for `TextDecoder`) "for compatibility reasons" [07:33:06.0013] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/wtf/text/text_codec_utf16.cc;l=73 [07:33:20.0722] annevk: hsivonen Is this a thing that was ever discussed? [07:39:24.0422] Seems bad. I suspect we might be able to fix it like we did the recent JSON/UTF-8 bug. [08:16:48.0056] Andreu Botella (he/they): I'm pretty sure it's considered a bug (EOF behavior has been discussed a lot, including that browsers do it badly), might even be filed [08:17:21.0161] Andreu Botella (he/they): unfortunately doing the easy "blame" thing on that file seems hard, suspect that comment was added a long time ago [08:22:59.0223] yeah, and the blame for this test suggests that whatever compatibility constraints (IE I assume) no longer apply, since lone surrogates at EOF used to decode as is and were later changed [08:22:59.0871] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/encoding/char-decoding-truncated.html [08:35:01.0886] > <@andreubotella:mozilla.org> annevk: hsivonen Is this a thing that was ever discussed? I vaguely remember discussing something along those lines with zcorpan . I don't recall any reported breakage from Gecko fixing that. [08:35:12.0995] Fixing in the sense of generating the U+FFFD. 2021-11-06 [14:18:03.0718] i think this is the right place. i had a question about the html spec for focus when the currently focused element is removed from DOM. when that happens, the spec explicitly says focus should go to body. why? wouldn't focus going to the nearest focusable parent be more desirable? 2021-11-08 [00:16:35.0175] annevk, Jake Archibald, how would you like to proceed with https://github.com/whatwg/fetch/pull/1329? annevk you've raised some questions about how this would apply to worker, I think all answers are valid but want to proceed somehow [01:29:01.0058] Noam Rosenthal: I'm under the weather this week, but I think we need to tackle the service worker part as well; there's not many hits for "terminate" in SW, but there's a few and we cannot just break the system [01:29:35.0381] Noam Rosenthal: putting a Living Standard in an inconsistent state is not something I'm happy with if it can be avoided [01:29:46.0739] annevk: hope you get well soon :) [01:31:19.0834] annevk: Currently SW references the somewhat handwavy "when the Fetch is terminated" which is an exported link that is still going to be there, I don't think we're leaving it more inconsistent than before. But I don't mind posting a PR to SW that makes it explicit with a controller, if that's the direction [01:34:19.0944] Noam Rosenthal: yeah, that sounds good to me still. I wish others would chime in a bit more or at least say something to the effect of "sounds reasonable, can't think of anything better". [01:35:03.0600] annevk: cool, I'll propose the PR, and hopefully it would be enough of a strawman to get some "sounds reasonable" or "let's do this differently" [04:19:42.0922] annevk: I thought as an alternative to returning a controller, to emit an "onFetchStarted(controller)" from both fetch and SW. This way the processes as they are today don't need to change and everything can still work. It might make my patch quite simpler. WDYT? [04:20:26.0552] ... otherwise I need to turn HTTP fetch into something that "awaits" fetch or make a lot of changes in fetch to make internal algorithms asynchronous [04:21:50.0565] > <@hsivonen:mozilla.org> I vaguely remember discussing something along those lines with zcorpan . I don't recall any reported breakage from Gecko fixing that. I don't remember what the compat problem was here [06:36:46.0908] > <@noamr:matrix.org> annevk: I thought as an alternative to returning a controller, to emit an "onFetchStarted(controller)" from both fetch and SW. This way the processes as they are today don't need to change and everything can still work. It might make my patch quite simpler. WDYT? https://github.com/w3c/ServiceWorker/pull/1612 and a new revision of https://github.com/whatwg/fetch/pull/1329 address this. (cc Jake Archibald ) [12:31:47.0842] https://fetch.spec.whatwg.org/#concept-scheme-fetch mentions "URLs such as "about:config" are handled during navigation and result [...]" Where exactly are these URLs handled in navigation? [12:44:32.0503] > <@domfarolino:matrix.org> https://fetch.spec.whatwg.org/#concept-scheme-fetch mentions "URLs such as "about:config" are handled during navigation and result [...]" Where exactly are these URLs handled in navigation? https://github.com/whatwg/html/issues/2414 2021-11-09 [00:26:45.0366] Dominic Farolino: maybe it should say "ought to be handled" 🙂 [03:18:18.0973] does wpt have some way to close alert() and similar popups? [03:18:23.0572] jgraham: ^ [03:35:40.0882] 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. [03:36:13.0094] ok. I was thinking to write some test for beforeunload, but perhaps I'll use mochitest for now [03:39:36.0172] 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. [03:41:17.0160] https://w3c.github.io/webdriver/#user-prompts talks about alert/confirm/prompt, and about implicitly closing beforeunload prompt [03:41:28.0875] I think I'd prefer to explicitly close beforeunload [03:42:49.0737] 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 [03:42:58.0491] * 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 [05:44:15.0222] 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 fiel this under "good candidate for a post-WebDriver-BiDi world" [05:46:10.0916] ok [05:46:22.0466] 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 :/ [05:46:38.0269] * 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" [05:46:54.0719] But still, not going to do that today :) [06:13:46.0608] 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? [06:18:42.0710] 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 [06:19:17.0624] Hope that's not too ambiguous 🙂 [06:20:19.0396] Nic Jansma: we do need a GitHub organization listed there, though [06:23:05.0600] 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 [06:23:46.0942] Nic Jansma: sounds good, thanks for keeping it up-to-date! [07:03:19.0597] > <@jgraham_:matrix.org> 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. Well, also a RFC and stuff, right? I recall adding such things to WPT to be quite a process. [07:11:25.0736] Right, hence "against wpt in gecko" [07:12:17.0513] 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. [07:15:31.0720] 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. [07:24:19.0321] Speaking of RFCs, ping on https://github.com/web-platform-tests/rfcs/pull/98 [08:44:13.0832] OK so the note in the fetch spec is wrong then, and these URLs are not explicitly handled anywhere in HTML's navigation [08:44:43.0486] (whoops that was in response to andreu -- my client hadn't updated and I saw no messages in between :) ) [11:34:58.0374] 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/ [12:17:57.0428] 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..." [12:18:06.0083] so it sounds like both specs will probably be around for a while [12:24:32.0448] thanks for the response, kind of a bummer i guess, but it does seem like the file system access stuff is a superset [12:24:34.0789] ¯\_(ツ)_/¯ [14:10:47.0521] Josh C: to further complicate things: https://github.com/whatwg/sg/issues/176 [14:11:12.0580] > 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. 2021-11-10 [23:49:53.0958] Whatever Entries API exposes might well be reasonable to expose through file system handles instead, I haven't seen a proposal for that though. [04:53:19.0650] The rest.livecode.world rosters are working again via https:// – Thank you. 2021-11-11 [20:03:15.0501] Henllo. I'm expanding my knowlede in order to get my money back after being scamed :') help? I found this inspecting element on the website trying to get to the domain but I'm not so versed in this [20:03:55.0785] I know for experience that I can get away with something like this [21:52:34.0224] TabAtkins (or anyone who may know): are the old Web IDL spec stylesheets still accessible somewhere? [21:57:59.0234] DerekNonGeneric: yeah it's just the Bikeshed default stylesheet [22:03:07.0289] TabAtkins: oh, yeah, they are indeed similar, but alas still no dark mode; was looking for the rest of this gist that i happened to save a while ago https://gist.github.com/DerekNonGeneric/e3072db4ea16cc64e138512a4a95bf56 [22:15:16.0159] Oh the dark-mode colors are inserted separately from the stylesheet itself. Look at any Bikeshed-generated spec, like the CSS specs, you'll find them. [01:45:43.0732] Domenic: annevk : Hey, there was some agreement to remove from the spec, and I see the HTMLObjectElement doesn't have it anymore in the spec. However, it is still there in Gecko & Blink & WPT. [01:45:52.0232] Is that intentional? [02:42:54.0572] ntim: hmm, there was https://github.com/web-platform-tests/wpt/pull/27830 [02:43:02.0887] ntim: Gecko has an open bug still [04:04:35.0975] Morning all, I have a silly question about `DocumentOrShadowRoot` mixin in https://dom.spec.whatwg.org/#mixin-documentorshadowroot. If I have a shadow root, should I be able to use `getElementByTagName` since it's part of the mixin? [04:27:43.0770] AutomatedTester: I don't see it on the mixin? [04:28:00.0723] AutomatedTester: in particular, note how the mixin doesn't define any members (HTML defines some) [04:29:09.0801] ok, I thought (probably wrongly) that when I saw `DocumentOrShadowroot` that I could use the APIs interchangeable [04:31:22.0431] so, `getElementsByTagName` is not available then on a shadow root? [04:32:03.0659] AutomatedTester: that is only defined on Document and Element, so no [04:32:43.0858] AutomatedTester: I think you might have inverted the logic of mixins (or something to that effect) [04:33:03.0635] probably :D [04:41:03.0868] annevk: so to look inside the Shadow Root one would need to do something like `document.get...().shadowRoot.host.get...()` or something along those lines? [04:43:40.0449] AutomatedTester: it has querySelector() and getElementById() [04:43:52.0118] AutomatedTester: through DocumentFragment [04:44:30.0288] ahhh ok [04:44:50.0573] why is the API limited ? [04:46:53.0076] I'm not sure I understand what you mean [04:50:02.0964] Why are querySelector and getElementById but not the getElementsBy* APIs. [04:51:32.0501] My reason for asking is people are using selenium for working with web components but in Chrome 96, they can’t search for element’s anymore by tag name [04:51:47.0651] So want to understand the why so I can fix this properly [05:00:29.0170] They were never included as they're kind of legacy APIs [05:02:58.0110] Ok, thanks [06:13:09.0694] Have there been any web-API functions in the past that were later extended to accept more input types, instead of throwing errors? And if there have been any such functions, were there any web-compatibility and polyfilling problems? (I’m interested because of https://github.com/tc39/proposal-bigint-math/issues/17.) [06:14:05.0782] * Have there been any web-API functions in the past that were later extended to accept more input types, instead of throwing errors? And if there have been any such functions, were there any web-compatibility and polyfilling problems? (I’m interested because of https://github.com/tc39/proposal-bigint-math/issues/17.) [06:21:46.0589] jschoi: I think we've done that plenty of times, though coming up with examples is a little harder [06:22:16.0702] jschoi: e.g., the types you can pass to XMLHttpRequest's send() increased over time [06:22:44.0108] jschoi: the fallback there was stringification though, not throwing [06:23:23.0706] That’s similar, yeah. I’d love any more specific examples later if you or anyone else thinks of any; feel free to direct-message me or comment on that issue. [06:23:52.0326] Any Web Platform API function `fn` that originally threw a TypeError when given a certain value `x` but later was changed to not throw… [06:24:17.0896] jschoi: addEventListener's third argument was overloaded with a dictionary, that was a bit contentious, but still the right call imo [06:24:44.0781] jschoi: there too though I guess it didn't throw, since {} coerces to true [06:26:45.0018] Background: TC39 is considering doing something similar to some `Math` functions with BigInt inputs. `Math.abs(-1n)` currently throws a TypeError but this would extend it to return `+1n`. `Math.max(0, 1n)` would return `1n` because `0 < 1n` is valid. I have suspected that similar things have been done with web APIs plenty of times before, though of course I’d like to be able to give specific examples. [06:26:49.0138] * Background: TC39 is considering doing something similar to some `Math` functions with BigInt inputs. `Math.abs(-1n)` currently throws a TypeError but this would extend it to return `+1n`. `Math.max(0, 1n)` would return `1n` because `0 < 1n` is valid. I have suspected that similar things have been done with web APIs plenty of times before, though of course I’d like to be able to give specific examples. [06:28:30.0413] jschoi: all the path overloads in https://html.spec.whatwg.org/#canvasdrawpath are additions, but also changes the number of arguments [06:29:19.0701] I wonder if that's the sort of thing you can add a use counter for, to see if any sites are currently relying on bigints throwing there. Maybe js engines are too low-level to support use counters though. [06:31:50.0788] Telemetry data would be useful, but I struggle to think of a way in which throwing behavior would actually break something…Why would anyone already be supplying mixed Number/BigInt inputs to Math functions? And web APIs have done function-domain broadening before already, e.g., with those CanvasDrawPath extensions and XMLHttpRequest examples from annevk, without compatibility problems. But yeah. [06:32:14.0415] * Telemetry data would be useful, but I struggle to think of a way in which throwing behavior would actually break something…Why would anyone already be supplying mixed Number/BigInt inputs to Math functions? And web APIs have done function-domain broadening before already, e.g., with those CanvasDrawPath extensions and XMLHttpRequest examples from annevk, without compatibility problems. But yeah. [06:34:06.0882] So I agree that in general this doesn't feel like it would be a very risky change. But experience suggests that it being hard to rationalise why someone might use a feature in a specific way doesn't mean that no one is depending on that behaviour in practice. [06:35:41.0299] Or to quote the /topic; "please leave your sense of logic at the door" :) [06:36:43.0669] I don't think we ever really did that kind of study when the current behavior is an exception though [06:36:59.0083] Removing exceptions has always been considered acceptable [06:37:31.0849] Yeah. Any more examples of removing exceptions would be super welcome. [06:37:47.0117] That's also why we like to start out with throwing if we can [06:53:21.0058] Yeah, it's definitely less likely that people depend on throwing. But it's at least conceivable to write code that expects anything that worked with Math.abs() must be a Number and would try to do some other operation that doesn't make sense with a bigint. I also vaugely wonder if typecheckers dinstinguish the two and if this could change type inference in a way that would require code changes for users of those tools. [06:53:47.0584] (but again, I have the general sense this is probably not a very worrying change) [07:00:56.0782] Yeah, depending on throwing and type checking are understandable concerns. I guess the big thing is that these concerns aren’t unique to Math; they have happened plenty of times elsewhere in web platform APIs, and like Anne said removing throwing always been assumed to be compatible there. But telemetry could be useful. These are Google employees who have been raising these concerns on that issue, so if they wish they could do telemetry to confirm that nobody actually depends on the exception before rolling it out. That’s what they would do for any similar change to a web API anyway, right? [07:01:46.0147] * Yeah, depending on throwing and type checking are understandable concerns. I guess the big thing is that these concerns aren’t unique to Math; they have happened plenty of times elsewhere in web platform APIs, and like Anne said removing throwing always been assumed to be compatible there. But telemetry could be useful. These are Google employees who have been raising these concerns on that issue, so if they wish they could do telemetry to confirm that nobody actually depends on the exception before rolling it out. That’s what they would do for any similar change to a web API anyway, right? [07:08:50.0955] top-level await used to be a syntax error [07:10:37.0987] import assertions were also a syntax error [07:11:00.0671] replacing errors w/ functionality seems to happen quite often [07:24:32.0031] I'd say that replacing "was a syntax error" with "not a syntax error" is safer than the equivalent with runtime errors. Although I'm fairly sure there are compat bugs relating to things that only succeed when a resource fails to load correctly, it's pretty rare for obvious reasons. [07:38:46.0211] jschoi: these are the relevant runtime errors you should likely be concerned about https://www.npmjs.com/package/@openinf/util-errors#Classes [07:38:53.0517] * Yeah, depending on throwing and type checking are understandable concerns. I guess the big thing is that these concerns aren’t unique to Math; they have happened plenty of times elsewhere in web platform APIs, and like Anne said removing throwing always been assumed to be compatible there. But telemetry could be useful. These are Google employees who have been raising these concerns on that issue, so if they wish they could do telemetry to confirm that nobody actually depends on the exception before rolling it out. That’s what they would do for any similar change to a web API anyway, right? (Telemetry data from Mozilla would also be welcome.) [07:43:27.0985] DerekNonGeneric: Node throw TypeErrors with the ERR_INVALID_ARG_TYPE code if given `Math.abs(0n)`, right? [07:43:43.0613] * DerekNonGeneric: Node throw TypeErrors with the ERR_INVALID_ARG_TYPE code if given `Math.abs(0n)`, right? [07:43:55.0428] No, wait, only Node APIs do that… [07:44:48.0212] Anyways, I’m not sure how Node’s error codes would be relevant to extending Math functions (or web API functions, for that matter). [07:45:17.0784] > I also vaugely wonder if typecheckers dinstinguish the two and if this could change type inference in a way that would require code changes for users of those tools. TypeScript and Flow both support union types, so such a change should not make users change their code. [07:45:25.0052] * > I also vaugely wonder if typecheckers dinstinguish the two and if this could change type inference in a way that would require code changes for users of those tools. TypeScript and Flow both support union types, so such a change should not make users change their code. [07:45:32.0014] `Math` is considered a "JavaScript core object", so the errors thrown are all the standard errors, which is fairly limited... [07:54:09.0156] > <@jschoi:matrix.org> DerekNonGeneric: Node throw TypeErrors with the ERR_INVALID_ARG_TYPE code if given `Math.abs(0n)`, right? yeah, just a `TypeError` [07:55:57.0089] Yeah. So I think Node’s error codes are probably not relevant to this issue, in contrast to things like XMLHttpRequest’s send addEventListener, addEventListener’s third argument, and CanvasDrawPath’s path overloads. [07:59:18.0857] perhaps not, but thought you'd be interested in seeing what Node's errors would be looking like (those are what the core developers use for Node APIs in case you were wondering) -- these errors pretty much map out all the possible value/type problems found in JS APIs (more sophisticated than Web APIs even) [10:08:44.0375] annevk: Domenic : I'm referring to the IDL: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_object_element.idl;l=34?q=object_element.idl&ss=chromium [10:09:33.0217] useMap shouldn't be there [10:09:45.0249] It should: https://html.spec.whatwg.org/#dom-object-usemap [10:10:15.0296] It's like all the other legacy content attributes like codeBase and codeType; still reflected in IDL attributes. [10:11:06.0957] Domenic: ah thanks, urgh, I was looking at: https://html.spec.whatwg.org/#htmlobjectelement [10:11:14.0043] which is why I was confused [10:11:50.0298] Yeah, the "// also has obsolete members" separation is perhaps not worth the potential confusion it causes... [10:15:32.0759] I continue to favor a refactor whereby we have clear web developer and implementer sections for each element and fold all that stuff back in [10:18:22.0813] jschoi: CSS has done this sort of "previous invalid, now valid" addition a multitude of times. It's *occasionally* been problematic, but almost always fine. [10:19:22.0860] (The issues have largely been from when a property that previously only worked on a subset of elements started working on a new set as well; pages often accidentally over-apply properties, and if a property doesn't apply, that's not an error, so they just leave it in. Then the page's behavior changes when it starts being valid.) [10:19:47.0167] But when it's a *noticeable* error, as in the property fails to parse, but later it does, it's *usually* fine; exceptions have been rare. [10:22:59.0931] So this should be directly relevant to your case - if a method currently throws an error, but will stop doing so, it's *likely* to be fine. You can generally expect little to no upgrade pain, and when there *is* such a problem, it'll be a surprise anyway, so there's not much sense in fearing it. [10:31:12.0865] Relevant example of the opposite case is things like the aEL() "third argument becomes an option bag" case that annevk mentioned - it has the potential to *change* behavior that was previously valid (passing an arbitrary object, which'll get bool'd and treated as setting the "capture" option to true) into different behavior (passing an arbitrary object now invokes the option-bag behavior, which'll generally treat the "capture" option as false). [10:33:11.0679] Right, so the aEL change was even riskier in that passing an object bag did not originally throw an error. [10:33:50.0233] Yup. [10:34:19.0384] The alternative on record was four arguments. Still happy we dodged that. [10:35:02.0432] Oh yeah, not saying it was a bad idea, just that it was risky, and the sort of thing that one *should* anticipate problems with. [10:47:31.0137] > <@tabatkins:matrix.org> So this should be directly relevant to your case - if a method currently throws an error, but will stop doing so, it's *likely* to be fine. You can generally expect little to no upgrade pain, and when there *is* such a problem, it'll be a surprise anyway, so there's not much sense in fearing it. What do you mean by “when there is such a problem, it’ll be a surprise anyway, so there’s not much sense in fearing it”? [12:32:41.0207] It's a low probability event, and likely not one you can anticipate ahead of time 2021-11-12 [06:34:11.0226] sideshowbarker: Did https://github.com/whatwg/html/issues/2683 get some wpts? [06:34:43.0840] smaug: yes, gimme a minute, I’ll fetch them [06:36:01.0725] aha, https://github.com/web-platform-tests/wpt/pull/29405 [06:36:09.0813] maybe [06:37:45.0855] yeah — the actual tests can be run here: * http://wpt.live/html/webappapis/user-prompts/print-during-beforeunload.html * http://wpt.live/html/webappapis/user-prompts/print-during-unload.html * http://wpt.live/html/webappapis/user-prompts/print-in-detached-frame.html [06:38:08.0067] sideshowbarker: so does the print-during-unload.html pass with the patch? [06:38:18.0109] (gecko patch) [06:38:18.0354] yes [06:38:26.0828] ok, then an .ini file needs to be removed [06:38:42.0192] commented in phabricator [06:38:42.0328] OK, I can update the patch [06:38:50.0668] thanks [06:39:23.0482] did you already comment there about which exact .ini file? [06:40:54.0584] ah you did, thanks [06:43:19.0914] the setup is quite simple, the .ini files are under /meta when the tests are under /tests [06:43:38.0729] OK [06:45:17.0547] all right, updated the patch [06:45:28.0582] there were actually three .ini files to remove [06:45:40.0504] ah, other tests pass too, even better [06:46:25.0756] yeah [06:46:49.0536] sideshowbarker: do you have rights to land the patch? or should I? [06:47:50.0830] I can’t land it myself — I only have Level 1 commit access — so it’d be great if you could land it [06:48:45.0948] done. Hopefully there aren't any bizarre mochitests for this 🙂 But if there are, we can tweak those later. [06:48:55.0104] yup [06:48:58.0947] * done. Hopefully there aren't any bizarre mochitests for this 🙂 But if there are, we can tweak those later. [06:49:25.0326] thanks much 2021-11-14 [00:30:05.0577] annevk: Domenic I am going to talk about AbortController in a conference tomorrow and Node.js using it. I am going to mention my involvement and use my interactions as an example of the WHATWG process being open/inclusive. I can either name the involved people (you two, Jake and maybe a few others) or the org itself. My intuition is to name the org and send people the links rather than the people in the discussions - if you have a preference other way or a "media guidelines" thing let me know. [00:30:51.0022] My two slides about it are that I wasn't a part but was still interested and I was able to participate in discussions and meetings which was very inclusive compared to other projects and efforts I was involved with. 2021-11-15 [03:18:43.0166] This might be of interest: https://twitter.com/seldo/status/1459957460932857857 [04:06:56.0645] annevk: hope you're feeling better! we have a few pending things when you get a chance (controller & preloads) [06:51:22.0967] Hey, this might be interesting from AbortSignal/CancelToken discussion PoV https://github.com/tc39/proposal-iterator-helpers/issues/162 [06:52:16.0163] If someone like Domenic or annevk could weigh in it would be appreciated but I don't want to tag you there directly without permission [07:19:03.0436] Doesn't seem like a super-productive discussion :-/ [07:37:54.0003] I agree and that's unfortunate - but I think part of is is that they're not aware of how AbortSignal can be made to work with the language [07:38:23.0017] Noam Rosenthal: heya, I hope to have time tomorrow [07:39:20.0133] > <@annevk:mozilla.org> Noam Rosenthal: heya, I hope to have time tomorrow Thanks, whenever is convenient [07:44:57.0621] Benjamin Gruenbaum: added a comment, although I'm not sure if it being host-defined would work for enough TC39 participants [07:45:30.0488] ֿThanks [14:20:28.0949] Lots of nice fixes for spec-compliance nerds in new Safari TP: https://webkit.org/blog/12040/release-notes-for-safari-technology-preview-135/ e.g. document.open(), javascript: URL stuff, noopener/noreferrer/opener/target="" stuff. It warms the heart. [15:54:17.0157] Hello everyone, I ran into a micro-markup problem, I'm trying to set up a review, but it doesn't work (the 'itemReviewed' field is missing), can anyone help, I've been suffering for several days, here's my page https://dymok.pl/pl/premix-smoke-paradise-6040/63-smoke-paradise-kaktus-truskawka.html 2021-11-16 [17:08:07.0722] Chromium folks, Any objection to unprefix text-align: -webkit-match-parent ? https://bugs.chromium.org/p/chromium/issues/detail?id=1243333&q=match-parent&can=2 I'm looking into doing it for WebKit, but before I proceed, I'm just wondering if we need to keep the prefixed value for compat at all (and it would also be nice if Chromium unprefixed at the same time too). Note that Gecko is already shipping only the unprefixed version [20:03:11.0563] ntim: probably best to leave a comment on the bug; we unfortunately have mostly spec folks hanging out here 2021-11-17 [16:59:17.0409] dont swear [16:59:43.0300] lol [12:26:46.0777] https://blog.whatwg.org/ appears to be down [12:54:48.0011] I'll kick it again... sigh. Should investigate trying a move off of DigitalOcean to see if that's the problem, I guess, or if we're bad WordPress admins. [14:21:49.0178] Thanks Domenic 2021-11-18 [01:21:03.0385] smaug: https://phabricator.services.mozilla.com/D131050 is maybe now ready to be merged (can’t merge it myself because I lack the perms) [07:54:34.0355] sideshowbarker: ok, will do [07:55:23.0602] sideshowbarker: hmm, error [08:40:10.0159] smaug: error? [08:40:40.0238] sideshowbarker: those inis make android as passing and others with error [08:40:48.0197] but it is Android which is failing, no? [08:40:56.0008] (because the method isn't there) [08:43:32.0158] Yeah those ini files don't make much sense; a subtest can't get the status `OK` or `ERROR`, only a test file. [08:45:45.0945] I'd expect ``` [print-during-beforeunload.html] expected: if os == "android": ERROR ``` and similar for the other files. [08:46:05.0790] Ok, then I need to change those to cause the test to just not be run on Android, right? [08:46:46.0653] Yeah you could do that as well if we're never going to implement `print()` on Android. [08:47:24.0650] Which would be something like ``` [print-during-beforeunload.html] disabled: if os == "android": ``` [08:47:52.0651] or just keep the FAIL for android [08:48:07.0939] (and pass elsewhere) [08:51:15.0332] Oh yeah, I guess my first suggestion is wrong if the test catches the exception, in which case it will be `FAIL` [08:51:25.0716] For the subtest, not for the top-lvel test [14:00:46.0113] Hello folks 👋 and sorry in advance if this is not the right channel to ask something like that :P I have a question on the following example: `Go to the new page after triggering a function!` I would expect that the onClick function would run before the navigation happens to the `/new-page`. Is there a chance that the navigation would happen without executing the function? Can you point me to the documentation that proves that in the https://html.spec.whatwg.org/ ? (I'm searching for hours and I can't find anything relevant) [14:07:17.0442] nmnbd: it is not at all trivial to figure out how this is specced, so happy to help :). The good news is that it is specced. Hyperlinks causing navigation is done via https://html.spec.whatwg.org/#the-a-element:activation-behaviour . Now, what is activation behavior, and how is it positioned relative to click handlers? It is defined in https://dom.spec.whatwg.org/#eventtarget-activation-behavior . And the key reference is https://dom.spec.whatwg.org/#ref-for-eventtarget-activation-behavior%E2%91%A5 . I.e., when dispatching click events, we run activation behavior in step 11 of the dispatch algorithm. Whereas, we run event handlers (deep inside) step 5. So indeed event handlers are guaranteed to come before navigation. [14:47:24.0324] I see.. does the function have to be quick enough and run between step 5 and 11, otherwise will be interrupted by the navigation? 2021-11-19 [17:57:15.0213] The function has to be synchronous [21:25:16.0428] XML fragment serialization algorithm links to https://w3c.github.io/DOM-Parsing/#dfn-xml-fragment-serialization-algorithm > Parsing concepts: a fragment parsing context; the HTML fragment parsing algorithm; the HTML fragment serialization algorithm; HTML parser; parsing XHTML documents; the XML fragment parsing algorithm; the XML fragment serialization algorithm; XML parser; [XML fragment serialization algorithm] links to https://www.w3.org/TR/html5/single-page.html#xml-fragment-serialization-algorithm It probably should be https://html.spec.whatwg.org/#serialising-xhtml-fragments [21:25:57.0278] https://www.w3.org/TR/html5/single-page.html#xml-fragment-serialization-algorithm doesn't exist [07:15:37.0877] Yep, lots of tech debt in the DOM-Parsing spec [07:15:52.0947] annevk: are you OK merging https://github.com/whatwg/streams/pull/1182 or did you want to wait for mgaudet? [07:52:25.0648] Domenic: how about I leave a message with him and you merge later today if you hear nothing [07:52:34.0609] Sounds good [07:54:58.0222] Domenic: hi, we're working on wasm modules on the web :) [07:55:13.0639] Oh, great to know! [07:57:01.0094] Domenic: it's fine to merge it now 2021-11-21 [08:19:36.0234] I am super confused about cancellation which is nothing new in the last few years :) I'll wait until it's not a Sunday though. Opened an issue about "tagging" cancellation. [08:20:34.0751] I feel strongly there should be a good cancellation story for developers authoring code and `reason` is really cool but also a concern. I want to focus on other stuff (learning how to contribute to WebIDL and working on symbols as event names) but I am happy to try and set up a meeting/discussion about cancellation. 2021-11-22 [00:52:01.0291] I like Domenic's explanation in the issue. That AbortSignal can be thought of as an "ExceptionSignal". The way we did aborting it was a never a third completion state after all. [03:52:33.0973] annevk / Domenic : ping re. my 3 pending timing-related PRs when you get a chance :) https://github.com/whatwg/fetch/pull/1311 https://github.com/whatwg/html/pull/7260 https://github.com/whatwg/html/pull/7339 [04:15:30.0540] So I was giving it a try at rewriting Deno's implementation of timers, and I noticed some non-timer WPT tests failing [04:16:11.0304] Turns out, according to the spec, calling `clearInterval` inside an interval's callback should _not_ clear it – but every browser does [04:16:58.0217] The handle's entry in the map of active timers is set no matter what in the timer initialization steps for the next iteration of the interval [04:17:52.0767] * The handle's entry in the map of active timers is set no matter what in the timer initialization steps for the next iteration of the interval [04:38:56.0837] Can you elaborate? Doesn't the spec synchronously mutate the map of active timers? [04:40:00.0885] After the callback, if `repeat` is true, the timer initialization steps are run again, whether the handle is in the map of active timers or not [04:40:28.0109] And the timer initialization steps, in step 14, will add the handle to the map of active timers [04:44:32.0233] Ah I see. It should probably do the same check as it does in step 1 of the task, after executing the callback. [04:44:40.0984] Indeed [04:57:44.0132] Noam Rosenthal: 1311 still seems to have unaddressed comments from Yutaka [04:59:04.0282] Noam Rosenthal: also, is the discussion with Yoav Weiss and npm1 resolved? Did anything change as a result? [05:00:45.0120] Going to leave the others to Domenic. [05:00:58.0573] I've addressed them by changing the scope of the PR for what's already implemented modulu a few open bugs. Anything missing from the discussion Yoav? [05:04:52.0043] I see, excluding non-HTTP(S) and abort network errors. I guess that works. [05:05:23.0266] Yutaka's comments still seem applicable though. [06:18:42.0472] There's an open question of who would implement this in Chromium, but that doesn't imply Chromium is not interested in implementing [09:22:04.0938] Yoav Weiss: can you make this clearer in the PR discussion? It seems chaotic to read right now from the Chromium perspective 2021-11-23 [18:17:41.0584] Domenic: should https://github.com/web-platform-tests/wpt/blob/628af0fd55db95d785a63484882998343e3a069e/html/semantics/interactive-elements/the-dialog-element/dialog-focus-shadow.html#L40-L47 focus an element inside the shadow dom? [18:18:57.0980] because the shadow dom is before the `focus-me`? [18:19:40.0808] sefeng: Yes I think you are right [18:20:02.0853] focus-me should be moved to the very first button [18:21:03.0230] Domenic: we don't need to move this one, because the one before this template does that already, I think? [18:22:12.0154] Not sure what you mean? I think the test would still be valuable since it shows that autofocus="" is ignored [18:22:27.0095] yeah, sorry, I misunderstood [18:22:50.0384] I'll fix it and ping you for review [18:23:18.0977] Great, thank you for spotting! [18:37:56.0846] Domenic: so before all these generic focus delegates algorithm, when there's a nested shadow dom host with no delegates focus, we don't delegate the focus to this shadow dom. [18:38:35.0472] but now it seems that we can delegate the focus to this shadow dom [18:48:55.0919] I am looking at these two tests https://github.com/web-platform-tests/wpt/blob/628af0fd55db95d785a63484882998343e3a069e/shadow-dom/focus/focus-method-delegatesFocus.html#L271-L284 and wondering which step makes the behaviour different [01:28:58.0325] Hi. I have a couple questions on how to integrate the URL standard in a specification (ping annevk I guess 😊) [01:32:55.0107] In EPUB, we're now refer to the URL standard. EPUB is basically a collection of web resources in an container (called "Abstract OCF Container"); practically, it's a ZIP. In this container, files refer to each other using relative URL strings (with optional fragments) [01:34:08.0903] What we'd like to do, is normatively disallow relative URL strings that "leak" outside the container. For instance "../../../../secret" [01:36:21.0161] So we're trying to define what is a valid relative URL string in the contexts of EPUB. [01:40:51.0819] My question is: is it OK to say something along the lines of "in an EPUB container, a **relative-URL string** MUST be a **container-relative URL string**", and then define what we mean by **container-relative URL string**. In other words, we're trying to override the definition of "relative-URL string" of the URL standard by: - disallowing path-absolute URL strings - disallowing scheme-relative URL strings - further constraining path-relative-scheme-less-URL strings to ensure dot-dot path segments are balanced by other segments [01:42:08.0741] In some way it has a smell of monkey patching, but I can't see how to do otherwise. That's why I'm asking for advice to y'all 😊 [01:43:02.0311] * In EPUB, we now refer to the URL standard. EPUB is basically a collection of web resources in an container (called "Abstract OCF Container"); practically, it's a ZIP. In this container, files refer to each other using relative URL strings (with optional fragments) [01:43:39.0581] * So we're trying to define what is a valid relative URL string in the context of EPUB. [01:44:05.0519] see also https://github.com/w3c/epub-specs/issues/1912 [01:50:24.0535] rdeltour: have you checked what implementations do? If there is some kind of base URL in play I'd expect it to work similarly to `https://example.com/../` [01:51:18.0030] I suppose you could still have a desire to say that's invalid, but it isn't invalid for similar URLs in other contexts (if I remember correctly) [01:52:35.0144] so, implementations vary (EPUB is old and this was largely unspecified so far). We added a UA conformance criteria to specify how the implementation-specific base URL must be. But here we're trying to define authoring requirements (what string is conforming or not, before parsing) [01:54:09.0260] a conforming UA will parse '../../secret' to the same URL record as 'secret', but we'd still like to disallow the former, for better interop with legacy or non-conforming UAs. [01:56:16.0297] It seems somewhat reasonable to write such a requirement the way you proposed above. The one quibble is that URL validity is also part of the URL parser and you wouldn't really be able to change that. (It's written in two different ways for different audiences.) [01:57:18.0506] It also seems that long term the requirement would be moot, so maybe it's easier to just explain the situation in a note and strongly encourage folks not to create such URL strings. [02:03:36.0646] OK good. Yeah, we're only talking of subsetting valid URL strings, so the URL parser would still return an expected result. That it doesn't produce a validation error on some of EPUB-non-conforming strings is acceptable. As for explaining all that in a note: that's what we do in the current WD; but that requirement was normative before, and EPUB is a slow world so I believe we a normative definition makes more sense. [02:07:30.0166] I have another question if I may. Essentially for testing if a URL string is conforming I'm proposing the following (simplified) algo: 1. if not a path-relative-scheme-less-URL string, return false 2. if the result of parsing _url_ with "http://example.org/A/" does not start with "http://example.org/A/", return false 3. 2. if the result of parsing _url_ with "http://example.org/B/" does not start with "http://example.org/B/", return false 4. return true [02:08:44.0661] the use of test URLs is somewhat inelegant, but is simpler than redefining a custom parsing algo for counting that dot-dot path segments are balanced by other segments. [02:09:33.0924] any advice or comment ? [02:12:06.0544] * I have another question if I may. Essentially for testing if a URL string is conforming I'm proposing the following (simplified) algo: 1. if not a path-relative-scheme-less-URL string, return false 2. if the result of parsing _url_ with "http://example.org/A/" does not start with "http://example.org/A/", return false 3. if the result of parsing _url_ with "http://example.org/B/" does not start with "http://example.org/B/", return false 4. return true [02:15:41.0488] * OK good. Yeah, we're only talking of subsetting valid URL strings, so the URL parser would still return an expected result. That it doesn't produce a validation error on some of EPUB-non-conforming strings is acceptable. As for explaining all that in a note: that's what we do in the current WD; but that requirement was normative before, and EPUB is a slow world so I believe a normative definition makes more sense. [02:18:40.0419] That seems okay, perhaps with a comment explaining the setup. You'll need to do more serializing if you want to compare strings, but you did say it was simplified. [02:19:31.0066] OK thanks! (and yes the non-simplified version does serialization) [02:20:25.0367] Well, thank you annevk for the help. Much appreciated! [06:59:47.0041] Domenic: apologies for becoming a grumpy old man yesterday, I'll blame lack of sleep and the fact that this has been grinding for a long time lol [08:20:27.0725] > <@sefeng:mozilla.org> I am looking at these two tests https://github.com/web-platform-tests/wpt/blob/628af0fd55db95d785a63484882998343e3a069e/shadow-dom/focus/focus-method-delegatesFocus.html#L271-L284 and wondering which step makes the behaviour different Yes, these seem suspicious. It seems to me in both cases we should be focusing innerShadowChild? [08:20:58.0233] yeah I see the same thing [08:22:03.0698] ping emilio ^ [08:27:54.0761] sefeng: Domenic: Hmm, so per spec I believe you're right (https://html.spec.whatwg.org/#focus-delegate is the relevant section, and it is determining the target area without looking at nested shadow tree's delegateFocus). However I believe we should probably behave like the test? It feels weird that `delegatesFocus` allows to cross arbitrary shadow boundaries [08:28:34.0477] In Gecko what makes it behave differently is [this check](https://searchfox.org/mozilla-central/rev/f574930f8d5f65fc856783ff27674ada781f4570/dom/base/ShadowRoot.cpp#778) [08:28:55.0963] I am not sure... can we find an analogy with to help guide the intuition? [08:29:12.0462] well we can't because conceptually `` delegates focus [08:29:14.0547] Or just any semi-realistic example, would help me figure out which direction feels more right. [08:29:45.0667] But imagine we have a component that doesn't delegate focus. calling `myComponent.focus()` won't focus any descendant in the component [08:30:08.0610] Right, that's why it's helpful as an intuition pump... something like
<#shadowroot delegatesfocus=true>
.focus(), should focus the inner date textbox, right? [08:30:35.0398] Hmm yeah I think my example is wrong and yours is the relevant one... [08:30:37.0110] Yeah, but that's not the difference in those two tests [08:30:40.0370] right [08:31:39.0655] The test-case would be `
<#shadowroot delegatesfocus=true>
<#shadowroot>
` [08:31:52.0249] It feels weird that `inner.focus()` wouldn't focus the ``, but `outer.focus()` would [08:32:07.0129] Yeah, that is weird. [08:32:10.0574] OK so we don't want flat tree... we don't want shadow-including descendants... do we want something like shadow-including direct children? [08:32:39.0930] We want shadow-including descendants as long as the path to the ancestor delegates focus [08:32:55.0677] As in, shadow-including descendants, but without recursing into shadow trees without `delegatesFocus` [08:33:07.0143] So inelegantly bespoke :P [08:33:31.0966] The spec text will basically need to do a custom tree-walk I guess? [08:34:15.0191] Perhaps? You can also do a filter instead looking at containing shadow trees [08:35:17.0925] Hmm yeah I'll play around [08:39:53.0326] Domenic: re https://github.com/whatwg/html/pull/7260/files#r755314056, I actually thought as an alternative to do a completely custom fetch, but take out "prepare request from link element" to a separate function... this way we won't have ephemeral state associated with the element. WDYT? [08:41:14.0102] Noam Rosenthal: yeah I thought of that too. I kinda like the ephemeral state bit slightly more, since it makes it more clear this is a special case. But I could go either way. [08:42:55.0653] Domenic: OK, yea, I was going backwards and forwards with this but I think it's better to have it in a closure (completely custom fetch, with reusing of prepare-request) as it eliminates weird edge cases of what happens if the element changes and re-fetches before the response returns. [08:43:33.0822] Fair point! [09:11:39.0906] Domenic: revised in that spirit (+ fixed/responded to other comments). [11:33:50.0217] emilio: sefeng: so if we stick with our plan of using the same focus-delegation logic as delegatesFocus, that means most of the tests in https://github.com/web-platform-tests/wpt/blob/master/html/semantics/interactive-elements/the-dialog-element/dialog-focus-shadow.html change result, since we won't traverse into non-delegatesFocus shadow trees. That seem OK? [11:43:28.0179] Unclear if they should use exactly the same steps... But probably? [11:57:28.0107] seems okay to me 2021-11-24 [07:24:25.0127] Domenic: FYI: https://github.com/whatwg/storage/pull/130 also failed participation check (I usually fix these by just telling participate to update the PR) [07:25:46.0490] Domenic: we should maybe have a better endpoint for that. E.g., I can browse to https://participate.whatwg.org/agreement-status?user=annevk&repo=storage and submit the URL of that PR there and it all works out, but it's a lil weird to have to fill in a (random) user and repo. [07:26:54.0221] The logs look fine... the webhook payload was delivered and the server sent back a 204 [07:27:02.0575] I guess we could add more logging, and maybe send that back instead of a 204 [07:28:06.0984] Like maybe some random thing happened which caused one of the early bailouts in this function to be hit before we got to createCommitStatus(): https://github.com/whatwg/participate.whatwg.org/blob/main/lib/pr-webhook.js#L6-L40 [07:36:04.0235] Domenic: wdyt of a spec change to prevent focusing steps on disconnected ? This is already what we ship in STP fwiw: https://wpt.fyi/results/html/semantics/interactive-elements/the-dialog-element/dialog-focusing-steps-disconnected.html?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&q=the-dialog-element [07:37:25.0153] https://html.spec.whatwg.org/multipage/interactive-elements.html#dialog-focusing-steps [07:37:41.0397] ntim: I think the spec already does that. Or rather, it runs the focusing steps, but because it finds nothing focusable, the focusing steps are a no-op. [07:37:46.0273] "If subject is inert, return." -> "If subject is disconnected or inert, return. [07:38:17.0089] The spec even has a note: "If control is not focusable, this will do nothing. For modal dialogs, this means that any earlier modifications to the focused area of the document will apply." [07:38:33.0906] (But, disconnected modal dialogs already threw in step 3 of showModal()) [07:38:45.0217] * (But, disconnected modal dialogs already threw in step 3 of showModal()) [07:39:13.0542] wondering why the test fails in Chrome & FF [07:39:26.0829] Yeah fair question [07:40:15.0443] Looks like Chrome resets focus to body [07:41:54.0998] yeah, it could have worked this way as well in STP, it was an intentional choice from me to just skip focusing steps [07:42:28.0170] Domenic: I think "Run the focusing steps for control." means focusing the body when control is disconnected for current implementations [07:42:46.0046] Oh, that's weird [07:42:49.0102] (FF included) [07:44:19.0516] ntim: not per my testing, in FF and Chrome: https://jsbin.com/fokusafumi/edit?html,console,output [07:45:24.0768] that's weird [07:46:06.0116] if I remove https://webkit-search.igalia.com/webkit/source/Source/WebCore/html/HTMLDialogElement.cpp#126-127 from webkit, it also does the same as ff and chrome [07:52:16.0512] Domenic: oh, the old version of the spec had this: https://webkit-search.igalia.com/webkit/source/Source/WebCore/html/HTMLDialogElement.cpp#154-155 [07:52:30.0333] which basically sets focus to body [07:53:06.0926] Ah, fascinating [07:54:15.0188] Our earliest commit snapshot (i.e. the first version of the spec after the move to GitHub, in 2015) doesn't seem to have such a step: https://html.spec.whatwg.org/commit-snapshots/c9e804f04d03a0658bfa689cb0f368a4d2e37936/#dialog-focusing-steps [07:58:23.0517] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_dialog_element.cc;l=73-77;drc=de68be3f18ba99cc01d75903e167ca09bade253c?q=html_dialog_element&ss=chromium [07:58:26.0994] chromium does this too [07:58:46.0774] let me remember the context [08:00:55.0709] similar stuff in FF: https://searchfox.org/mozilla-central/source/dom/html/HTMLDialogElement.cpp#186-197 [08:03:01.0362] Domenic: from what I recall, that made sense to me because otherwise focus would stay on an inert element in the showModal case [08:03:11.0103] but yeah right it's not part of the spec [08:03:57.0574] Hmm interesting to think about the showModal case [08:04:33.0644] I'm happy to just fix Chromium to pass the test you pointed out since it seems more correct anyway... but yeah I wonder what the consequences would be of deleting that line. [08:05:27.0556] I think the risk is to keep focus on an element behind the dialog [08:05:42.0424] in the event that the control is not focusable [08:06:04.0722] and in the showModal case that might be bogus [08:10:27.0266] So the spec solves that in another way, which is the focus fixup rule [08:10:42.0242] When the modal dialog makes everything inert, we hit https://html.spec.whatwg.org/#focus-fixup-rule [08:10:49.0579] See https://html.spec.whatwg.org/#dom-dialog-showmodal step 6 [08:11:09.0766] But focus fixup rule is very "action at a distance" so I can easily believe implementations need more special code for that [08:11:32.0615] I think I remember adding that paragraph explaining the focus fixup rule connection so hopefully we added tests at the same time... [11:45:40.0863] Domenic: so I guess the right logic should be `else if (is_modal) { setFocusedElement(nullptr) }` [11:46:32.0744] I guess those specific LoC were specifically to implement the fixup rule [11:59:52.0591] Yes, sounds right to me [12:08:28.0597] Domenic: cool, are you planning to fix this in Chromium? [12:08:57.0093] ntim: yeah, we have a bunch of changes queued up for after https://github.com/whatwg/html/pull/7361 lands [12:09:18.0326] just wondering if i should write WPTs [12:09:56.0032] Domenic: oh I see you have a WPT PR: https://github.com/web-platform-tests/wpt/pull/31724 [12:10:50.0626] ntim: didn't this conversation start with an existing WPT you already wrote? i.e. https://wpt.fyi/results/html/semantics/interactive-elements/the-dialog-element/dialog-focusing-steps-disconnected.html?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&q=the-dialog-element :) [12:12:03.0082] Domenic: planning to make this change in WebKit too: https://webkit-search.igalia.com/webkit/source/Source/WebCore/html/HTMLDialogElement.cpp#126-127,154-155 [12:12:20.0225] Awesome, great to hear [12:13:10.0384] Domenic: does it still make sense to have "If subject is inert, return."? [12:13:17.0588] * Domenic: does it still make sense to have "If subject is inert, return."? [12:13:26.0596] wouldn't that be covered by the fixup rule? [12:13:32.0883] Interesting. Yes, I think you're right. [12:14:36.0241] Domenic: wondering if this changes anything for non modal dialogs [12:15:32.0156] (thinking about which tests I should write) [12:18:36.0018] Maybe we should just update https://github.com/web-platform-tests/wpt/pull/31724 to focus a random (connected) element on the page between tests. And if there is no focus candidate (which occurs in one or two of the tests) then we test that that element is focused, instead of testing that it's body. I.e. test that it didn't get reset to body. [12:21:06.0517] yeah that makes sense, it could alternate between body and an element with explicitly focus on [12:22:08.0981] Done in https://github.com/web-platform-tests/wpt/pull/31724/commits/6cbfb3b76b68ef9eec9e44544ac424c8b6eb7d48 [12:23:24.0956] Like I told sefeng on that PR, feel free to grab those tests and use them locally / export them after, instead of waiting for merge on the WPT repo. Writing tests separate from implementation is a bit suboptimal here so I am happy to just provide a headstart for the people doing the implementation. [12:35:05.0291] Domenic: https://github.com/whatwg/html/pull/7366 [12:35:23.0899] Awesome, thank you [12:37:25.0534] np, i haven't filled in implementation bugs, tests, since i assume this will probably be fixed in batch as part of the focus changes [12:38:17.0552] chromium already omits this step, nice [12:38:30.0940] * chromium already omits this step, nice [12:41:35.0562] Domenic: looks like Chromium & Firefox already don't have this step, so no need for impl bugs [12:43:31.0836] Perfect [12:51:55.0065] Domenic: thanks! can you merge the PR? [12:52:48.0393] Done [12:53:13.0002] thanks! 2021-11-25 [06:27:26.0737] <برانمي/ Branme> I have a question about showing the code to the user without it running in the background [08:22:07.0551] > For the purposes of interaction with other algorithms, an entry’s filename is the empty string if value is not a `File` object, and otherwise its filename is the value of entry’s value’s name attribute. [08:22:19.0639] Does anyone know if any spec uses this? Because XHR doesn't seem to [08:22:33.0004] https://xhr.spec.whatwg.org/#interface-formdata [08:25:13.0351] Andreu Botella (he/they): URL I think for application/x-www... and maybe multipart/form-data needs it? [08:26:28.0587] They might have used it before, but they don't anymore [08:26:53.0547] The filename normalization now happens here: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#converting-an-entry-list-to-a-list-of-name-value-pairs [08:26:56.0579] Right, I was about to say someone(tm) might have refactored that [08:27:08.0946] yeah 😄 [08:27:36.0089] I suspect that means we can clean that up, which is nice because it was always rather ugly [08:29:41.0685] I was working on a patch to fix the USV handling in WebKit, and I realized that the way I'm doing things might be easier to sell if entry names and values are defined as USV strings [08:30:02.0429] so I'm working on that now [08:30:20.0022] and the rest of https://github.com/whatwg/html/issues/6701 [08:31:36.0520] \o/ [12:06:09.0292] I guess https://github.com/whatwg/html/pull/7371 isn't actually editorial? [12:06:46.0511] The actual spec changes are editorial, but it's moving definitions 2021-11-26 [23:50:04.0143] I think that is editorial. It doesn't change how the standard is understood. [23:51:12.0859] https://github.com/whatwg/meta/blob/main/COMMITTING.md#title-prefixes has advice, though I'll admit that every now and then Domenic will correct me. It still doesn't come natural to me. [00:19:25.0966] Hello everybody here, You can consider me as someone accidently land out into this room. But I am really exciting to be here. and will really appreciate that if anyone here explain me a bit on its science ? [00:55:38.0866] Domenic: Filed https://bugs.webkit.org/show_bug.cgi?id=233514 & https://bugzilla.mozilla.org/show_bug.cgi?id=1743082 for WebKit & Gecko [00:55:53.0538] (also i'm doing the work for WebKit) [00:56:24.0569] emilio: sefeng ^ [08:23:16.0245] So I'm trying to work out how to talk about sandboxes / isolated worlds for WebDriver BiDi (Extensions will need something similar for content scripts). I kind of just want to sketch in the basics of how it works at the moment, but it would be good to start with a model that isn't total nonsense. So I'm leaning towards a model where the behaviour is explained as "in a sandbox, objects are accessed through a transparent wrapper object. When getting a property, if the property is defined on the wrapper, return that. Otherwise check if the property is defined on the wrapped object and, if it is, and the wrapped object is a platform object, and the property is part of the interface definition for the wrapped object, or is an internal slot, return the wrapped property value if it's an object, or the primitive value if it's not. When setting a property, check if the wrapped object is a platform object, and the property is part of the interface for that platform object, then act as if setting the property on the wrapped object. Otherwise set the property on the wrapper." Does that make any sense whatsoever as a model or is it going to run into insurmountable difficulties (I think it's similar to the actual Gecko implementation, but I'm not an expert)? If it does make sense, how to fit it into the formalism? I don't mind the wrapper objects being "magical", but does it make sense to claim that the sandbox itself is a realm and the wrapped objects are part of a different realm? That kind of makes sense at a high level, and matches how we want to expose it in the BiDi protocol but is it going cause problems with some invariants at the spec level? [08:26:45.0447] I kind of realise that this stuff doesn't match the theoretical model of ECMAScript etc. so there is probably going to be some amount of doing things that aren't intended (and maybe people won't like it), but it would be good to avoid unnecessary friction. [08:33:16.0621] I've been reading the Webstreams spec and working on porting some code running in Node to use webstreams. I came across two obstacles that I think are built into the current design. Would value hearing from others who know more about or have more experience working with this spec. Is this a good place to ask? Would it be ok/better to raise issue on whatwg/streams? [08:33:25.0157] 1. In a Readable/WritableStream's `start()` implementation (also in `read()` or `write()`) I sometimes want to gracefully cancel or abort the stream. For example, if a WritableStream is passed data of a type it doesn't handle, but I want the stream implementation to do some post-processing on the data it already received. One can't use the client-facing `cancel` or `abort` methods on the streams at these points, because the stream is typically locked. You can call `controller.error`, but (at least in Node 17.1.0's implementation and in the current web-streams-polyfill), this throws an error outside the scope of the stream implementation (so it can't be observed/caught by the implementation's `cancel` or `abort` routines). I'd be interested to hear whether this design is deliberate and what kinds of worksarounds I might consider. [08:33:31.0347] 2. There doesn't seem to be any way to observe errors/aborts/cancelations in an existing stream (that my code did not implement itself). Some Node code I'm trying to port calls `webstream.on('error', err => ...)` but I don't see any way to do something similar with webstreams. I considered having my code implement a TransformStream and piping the externally-provided ReadableStream through that. But I don't see any way to make the TransformStream observe errors in another stream piping into it. [08:37:10.0093] jgraham: at a high-level it sounds reasonable; "Proxy object" is the TC39 verbiage. You could look at WindowProxy for some inspiration. Defining that in detail seems quite involved though. [08:37:23.0847] Domenic: emilio sefeng , I wrote https://github.com/web-platform-tests/wpt/pull/31758 which formalizes the behavior implemented in Chrome/Firefox (though it fails in WebKit), although I'm not sure this is specified anywhere [08:39:08.0569] Should ::backdrop receive events from the associated element ? [08:39:39.0063] > <@dubiousjim:matrix.org> 2. There doesn't seem to be any way to observe errors/aborts/cancelations in an existing stream (that my code did not implement itself). Some Node code I'm trying to port calls `webstream.on('error', err => ...)` but I don't see any way to do something similar with webstreams. I considered having my code implement a TransformStream and piping the externally-provided ReadableStream through that. But I don't see any way to make the TransformStream observe errors in another stream piping into it. Whoops, I mean, it calls `nodestream.on('error', err => ...)` [08:41:28.0266] Jim Pryor: I think stream.closed ends up rejecting [08:41:45.0722] Someone else prolly knows better though [08:43:01.0457] annevk: Yeah, I have been looking at WindowProxy, that's pretty much how I ended up with "oh if we just override all the internal methods…" :) [08:43:02.0631] > <@dubiousjim:matrix.org> Whoops, I mean, it calls `nodestream.on('error', err => ...)` You can use `reader.closed.catch(err => { ... })` for that. [08:44:16.0712] And yes I agree it's quite a lot of work, this is why the aim in the short term is to have something that sketches out the requirements, because in reality browsers already have an implementation of this stuff and they aren't going to change the existing implementation to match the spec anyway [08:44:21.0414] jgraham: "just" is doing a lot in that sentence [08:44:59.0932] Fair :) [08:48:23.0518] jgraham: I wonder if implementations are truly creating proxy objects or if they are creating separate JS objects that point to the same backing IDL object [08:49:58.0241] jgraham: the former seems kinda painful for perf, especially if you'd also have to do it for website scripts (not sure how you'd avoid expandos leaking to extensions otherwise) [08:52:22.0161] annevk: I think Gecko and Blink are different here (I assume WebKit matches Blink). Blink basically creates a new JS reflector for each underlying C++ object. But Gecko I think is closer to having a proxy object as described (and a practial implication is that in Gecko you can get to the original JS reflector using `.wrappedJSObject` fram a sandbox) [08:52:37.0222] > <@dubiousjim:matrix.org> 1. In a Readable/WritableStream's `start()` implementation (also in `read()` or `write()`) I sometimes want to gracefully cancel or abort the stream. For example, if a WritableStream is passed data of a type it doesn't handle, but I want the stream implementation to do some post-processing on the data it already received. One can't use the client-facing `cancel` or `abort` methods on the streams at these points, because the stream is typically locked. You can call `controller.error`, but (at least in Node 17.1.0's implementation and in the current web-streams-polyfill), this throws an error outside the scope of the stream implementation (so it can't be observed/caught by the implementation's `cancel` or `abort` routines). I'd be interested to hear whether this design is deliberate and what kinds of worksarounds I might consider. > Hmm, controller.error() does indeed clear the queue, it's supposed to be for an "immediate" fatal error. You could do controller.close() for a ReadableStream, but then you can't signal an error. 🤔 [08:52:37.0345] * annevk: I think Gecko and Blink are different here (I assume WebKit matches Blink). Blink basically creates a new JS reflector for each underlying C++ object. But Gecko I think is closer to having a proxy object as described (and a practial implication is that in Gecko you can get to the original JS reflector using `.wrappedJSObject` fram a sandbox) [08:54:42.0089] jgraham: does that mean you can see expandos in Gecko? I guess one thing that would help me here is to have some examples 🙂 [08:55:16.0589] jgraham: I also wonder if we want to keep that setup in Gecko or if this is something we might change (we ended up changing things for `document.domain`) [08:56:17.0240] annevk: In gecko, if a window does something like `document.expando = 1` then from a sandbox `document.expando` is `undefined` but `document.wrappedJSObject.expando` is `1` (I believe) [08:56:56.0838] The Firefox UI code leans pretty heavily on the current implementation, so I wouldn't bet on it changing. [08:57:27.0544] I wonder how that works. Doesn't that mean that wrappedJSObject also has to be a proxy? [08:58:09.0905] I mean I don't think it really works in terms of ES proxies [08:58:23.0675] Yeah, but I guess that means that specifying this in a way that's agreeable to the various implementations might also be tricky and will end up being mostly hand-wavy... [08:58:47.0364] https://firefox-source-docs.mozilla.org/dom/scriptSecurity/xray_vision.html is the entrypoint to the documentation on what Firefox does [09:01:01.0881] Yeah, it's kind of "exciting" in that implementations aren't exactly the same, but also are very unlikely to converge, and in spec terms it's not super clear that exposing the concept of the internal state of an object being different from the JS observed state is OK/not going to cause people to be cross. [09:01:48.0579] But it's also a thing that exists in the real world and is needed by at least two popular platform-adjacent features (remote automation and extensions) [09:04:31.0118] jgraham: yeah not sure. Maybe you can come up with a way of writing it down where you just have requirements on observable behavior ( + some stuff that's implementation-defined). Having examples would help a lot with that I think. [09:05:26.0076] jgraham: and some explanation as to why there's no actual model, to not favor any particular approach. [09:05:31.0350] Jim Pryor: I think these questions deserve an issue in whatwg/streams. You're right, there's no way for a TransformStream to observe cancel or abort on its readable or writable end. I have personally had to do the same trick with piping through another identity transform in order to observe errors from the pipeTo promise. Not very elegant. 😛 [09:10:50.0034] annevk: Yeah that's kind of what I planned to do and then when it came to writing it turned out to be hard to reason about how precise one needs to be when this is interacting with existing specs to avoid breaking their models/invariants. Usually the answer is "everything needs to be precise, but here it's more like "you need to look like you're doing something reputable from the outside, whilst furiously handwaving the internals". So I think that's been pushing me towards something that looks more like a "real" definition, but maybe it's not actually helping :) [10:01:12.0741] Mattias Buelens: I've seen this in some code with nodestreams too. The scenario is, you have some outside-supplied readable stream (may be the readable end of a pipeline), that you want to observe and/or catch errors in. With node streams, I've seen code do `stream.pipeline(suppliedStream, new stream.PassThrough (), callback)` in order to catch errors raised by the supplied stream. I guess we're close to being able to do the same with webstreams, something like `suppliedStream.pipeThrough(new IdentityTransform()).catch(callback)`. Only issue is that `pipeThrough` returns the readable end of the TransformStream, instead of a promise. Whereas `pipeTo` provides a promise, but expects a writable destination. [10:01:14.0186] I guess what we'd have to do is: `function installCallback(suppliedStream: ReadableStream, callback): ReadableStream { const t = new TransformStream(); suppliedStream.pipeTo(t.writable).catch(callback); return t.readable; }` [10:04:40.0171] Thanks, was helpful to talk this through. 2021-11-29 [00:41:26.0556] Jake Archibald: good morning! I have a couple of SW patches waiting for review when you get a chance... https://github.com/w3c/ServiceWorker/pull/1620 and https://github.com/w3c/ServiceWorker/pull/1621 [01:09:31.0618] Hi annevk: We found some existing issue with `process response donein this comment: https://github.com/whatwg/fetch/pull/1311/files#r737407947 [01:10:12.0608] basically we call "done" when the network is done, but we never call it for http-cache/SW. For http-cache it's simple, but not sure yet how to integrate it with SW [01:15:08.0105] annevk: Maybe `network read complete` flag should be on a response instead of on the fetch, I think that would solve it [01:16:25.0385] How would it get set is the problem, no? It's interesting how the lack of progress events for streams is making a lot of this hard [01:16:36.0996] yea [01:16:48.0990] ideally this should all be related to the streams [01:16:53.0049] Perhaps the solution would be to have some kind of transform stream that reports when EOF is pushed and otherwise forwards [01:17:22.0794] isn't that equivalent to "teeing" the stream and fully reading one side of the tee? [01:18:15.0652] I thought reading had side effects, such as possibly influencing the speed of transfer [01:18:41.0755] yea but not observable side effects [01:19:07.0449] as far as observable behavior is concerned it should be equivalent, of course implementations can do something "faster" [01:20:28.0582] Maybe, I'm not too well-versed in this. It seems rather wasteful, but perhaps with an explanation of what it is doing it could work [01:20:29.0054] but maybe a cleaner solution would be to add some "control-flow" reader to a stream like you suggested [01:21:17.0276] Mattias Buelens do you have thoughts on any of this? [01:28:52.0827] Seems like maybe the cleanest thing would be that FETCH adds a transform stream that implements flush (https://streams.spec.whatwg.org/#dom-transformer-flush) but that is otherwise an identity transform stream [01:55:56.0951] annevk: doing ^^^ for only the SW case would solve the problem I think (for HTTP cache we can check cache-state on fetch finale). I'll jot down a revision and see what it looks like [01:57:59.0510] Teeing and then fully reading one side is not correct, since it doesn't respect backpressure. Piping through an identity transform stream that implements `flush()` would work. [02:00:41.0774] You could also use the promise returned by `pipeTo()` to know when the pipe has completed, and thus when the readable has reached EOF. But a transform stream with `flush()` is probably easier to reason about. [02:02:04.0221] great, thanks Mattias Buelens. Getting to it! [02:26:51.0980] Mattias Buelens: how do I define a `[=transform stream=]` with a custom flush, spec-wise? Seems like `{{Transformer}}` is a web-exposed class, while I want to stay in the "internal" realm [02:27:24.0096] See https://streams.spec.whatwg.org/#other-specs-ts [02:28:13.0788] For an example, see step 5.2 of https://fetch.spec.whatwg.org/#http-fetch [02:28:22.0403] perfect, thanks! [02:30:43.0358] > <@mattiasbuelens:matrix.org> See https://streams.spec.whatwg.org/#other-specs-ts Seems like `transformAlgorithm` is required though, is there something like an `identityTransformAlgorithm` I can use here or needs to be exposed? [02:30:55.0001] (I only want to customize flush) [02:34:04.0748] Hmm, doesn't seem like it. It's probably easiest to define your own `transformAlgorithm` that simply enqueues the given chunk (using https://streams.spec.whatwg.org/#transformstream-enqueue). [02:34:42.0634] You can copy the phrasing from https://streams.spec.whatwg.org/#create-an-identity-transformstream [02:54:29.0545] Done. annevk I think this made https://github.com/whatwg/fetch/pull/1311 a lot better... At `fetch finale` the response is either done and can be finalized, or we add a `TransformStream` at that point that reports `done` on `flush`. [02:55:03.0170] ... no need to deal with the network thread race conditions [05:15:15.0417] > <@noamr:matrix.org> Jake Archibald: good morning! I have a couple of SW patches waiting for review when you get a chance... https://github.com/w3c/ServiceWorker/pull/1620 and https://github.com/w3c/ServiceWorker/pull/1621 Thanks for the ping, I'll try to find time to catch up on issues there [05:22:16.0435] Noam Rosenthal, annevk, Domenic: https://github.com/whatwg/html/issues/7376 [05:27:37.0241] > <@andreubotella:mozilla.org> Noam Rosenthal, annevk, Domenic: https://github.com/whatwg/html/issues/7376 I believe getDeadline should be clamped to always be >=0, if that's missing in the requestIdleCallback spec it's an oversight and I'll add it, thanks for noticing. [05:28:07.0394] I haven't looked at `requestIdleCallback` in any depth, but this is an issue with the timers [05:28:53.0172] Andreu Botella (he/they): from the issue it seems like it's only a rIB issue, as that's the only place this deadline is relevant. so I guess I don't fully understand the issue. [05:29:07.0647] `setTimeout()` timers keeping an entry in the map of active timers even long after their callback has been run [05:29:13.0756] thus keeping the deadline in the past [05:30:05.0475] even if it's clamped to 0, that's probably not what you want for already-expired timers [05:30:38.0900] right, we now remove them from the list. Why were they kept in the list in the first place and how was that observable? [05:32:57.0076] The timer task (timer initialization steps, step 9) in the spec will not remove the entry from the map of active timers if `repeat` is false [05:33:05.0717] But see the note in step 13 [05:33:22.0391] I suspect Chrome does remove it [05:36:58.0220] Andreu Botella (he/they): I see, so for the purpose of repeating intervals, the spec is "lazy" and doesn't actually remove the timers from the map, which would have a strange effect on requestIdleCallback. The safest solution would be that the map value would have a boolean "expired" alongside the timer's deadline to let rIB ignore them [05:37:15.0863] Am I getting this correctly now? [05:38:10.0662] Or simply remove the entry from the map after the callback [05:38:17.0459] * Or simply remove the entry from the map after the callback [05:38:30.0871] Andreu Botella (he/they): we can't do that because of intervals... repeating means that someone actually canceled that ID [05:39:11.0074] but yea removing them and making sure intervals are handled correctly by rIB would also solve this problem [05:41:31.0926] I noticed this –and other timer issues– while rewriting the implementation of timers in Deno (even though we don't implement `requestIdleCallback` yet), and what I'm doing is just have step 9.5 run the timer initialization steps if `repeat` is true or remove the entry otherwise. [05:41:55.0130] Would this be an issue for rIC? [05:43:22.0156] this would be good for rIC, all that rIC cares about is the "next active timeout to pop" [05:43:32.0193] 👍️ 2021-11-30 [08:21:26.0073] annevk: not sure if you were expecting me to merge https://github.com/whatwg/fetch/pull/1345, but I don't have permissions to do so [08:23:43.0991] wanderview: implementation bugs still need to be filed and I figured I'd wait until Wednesday to give the email thread some time to comment if needed [08:23:57.0274] (that was the "modulo bugs") [08:24:05.0488] ah, ok... thanks [08:24:12.0721] sorry for my confusion [08:35:21.0068] wanderview: can you file a bug against WebKit? I think we're good otherwise. [08:35:34.0636] sure