| 02:46 | <othermaciej> | does anyone here know what happens in an IETF meeting other than WG meetings? |
| 02:47 | <Domenic> | Seems like a good question to ask on that thread... I found https://ietf.org/tao.html#rfc.section.3 |
| 04:00 | <annevk> | Domenic: smaug____ is not here |
| 04:03 | <annevk> | I support updating the mailing list with news and tweeting interesting threads |
| 04:03 | <annevk> | Happy to help next week |
| 09:12 | <tobie> | littledan: you should really split up your spec repo so you can add pr-preview to it. |
| 09:12 | <tobie> | littledan: |
| 10:36 | <foolip> | Ms2ger: the promise cleanup isn't on OKRs or anything, but Mike has only next week to work on it. Review appreciated, but I could to it too if you like. |
| 10:37 | <foolip> | Or at least someone who's being paid to, if it's not fun and rewarding. |
| 10:43 | <littledan> | tobie: Interesting idea. Seems like we'd need to do some work to integrate ecmarkup and pr-preview... another thing on my todo list I guess |
| 10:43 | <littledan> | I didn't know about that tool. thanks for the link |
| 10:44 | <tobie> | ecmarkup is a node project, right? It would be trivial to integrate as a post-processor. |
| 10:44 | <tobie> | littledan: happy to hook it up for you. |
| 10:44 | <littledan> | that'd be really helpful! |
| 11:25 | <Ms2ger> | foolip, how about I see what the PR ends up looking like, and I'll ping you if I won't have time? |
| 12:07 | <foolip> | Ms2ger: SGTM, thanks! |
| 13:07 | <foolip> | In https://github.com/whatwg/dom/issues/544 I don't see the string "compat". It seems unlikely to me that adding such a short and useful name on EventTarget would be web compatible, has anyone done any digging yet? |
| 13:07 | <foolip> | ^ annevk |
| 13:11 | <annevk> | foolip: at this point we don't have implementer interest although othermaciej did comment with some questions, so I'm not sure it's worth bikeshedding names |
| 13:12 | <annevk> | foolip: that thread is already way longer than is ideal, but not unexpected due to the excited around new things 😃 |
| 13:58 | <foolip> | annevk: ok, good |
| 14:18 | <annevk> | JakeA: "This also happens before unsetting the event's passive listener flag, so preventing default should be fine for spec-dispatched events" is not true |
| 14:18 | <annevk> | JakeA: unless you want to change all algorithms that dispatch an event and look at its canceled flag afterwards to wait for all microtasks to end first, effectively breaking compat of sorts |
| 14:19 | <annevk> | JakeA: as currently you can expect that by the time the microtask runs the spec-defined action has already happened |
| 14:19 | <JakeA> | annevk: huh, but aren't microtasks handled as part of calling the callback? |
| 14:20 | <annevk> | JakeA: hmm, I see, so click() and a normal mouse click would be different |
| 14:21 | <annevk> | JakeA: that's going to be somewhat confusing |
| 14:51 | <JakeA> | annevk: especially now EventTarget is constructible/extendable, we'll see more dispatchEvent usage |
| 14:58 | <smaug____> | Since I don't know the history behind AbortController and AbortSignal, why are they separate things? |
| 14:58 | <annevk> | smaug____: being able to hand someone a signal without giving away control |
| 14:58 | <JakeA> | smaug____: folks really wanted the ability to abort and the ability to be abortable to be separate |
| 14:59 | <smaug____> | Why wouldn't there be just Abortable object which inherits EventTarget (or possibly just have a getter for a promise which is resolved when aborted or something) |
| 14:59 | <smaug____> | Why they need to be separate? |
| 15:00 | <JakeA> | smaug____: eg, in a service worker, fetchEvent.request.signal will tell you if the browser wants the request to be cancelled |
| 15:00 | <JakeA> | this might be because some JS on the page called controller.abort(), or it might be because a tab closed |
| 15:01 | <smaug____> | hmm, why wouldn't request be EventTarget with onabort on it |
| 15:01 | <smaug____> | oh well, the ship has probably sailed |
| 15:02 | <JakeA> | smaug____: So you have onabort on requests & onabort on controllers? |
| 15:02 | <annevk> | smaug____: Request is carrying information around, it doesn't really represent an ongoing thing |
| 15:03 | <annevk> | smaug____: that also wouldn't really allow you to pass the signal around to other things that might need to react to it |
| 15:03 | <smaug____> | I would have expected request itself basically been the signal |
| 15:03 | <annevk> | (the ship has sailed, FWIW, but it would be good to have a shared understanding) |
| 15:03 | <annevk> | smaug____: so every API that takes a signal would have to take a Request? |
| 15:04 | <smaug____> | no |
| 15:04 | <smaug____> | signal could have been a mixin or so |
| 15:04 | <JakeA> | smaug____: https://developers.google.com/web/updates/2017/09/abortable-fetch#in_a_service_worker might help |
| 15:05 | <smaug____> | not really |
| 15:06 | <JakeA> | smaug____: is your proposal fetch(url, { signal: event.request })? |
| 15:07 | <JakeA> | I wanted there to be a clear distinction between "pls attempt to abort" and "this has aborted" |
| 15:07 | <JakeA> | With request.onabort, it wouldn't be clear which that was |
| 15:08 | <smaug____> | I guess I don't understand why we want the same signal in fetch(url, { signal: event.request.signal }) |
| 15:09 | <smaug____> | looks wrong to me |
| 15:09 | <smaug____> | but this is serviceworkers, so I stop looking at this now |
| 15:12 | <annevk> | smaug____: you want the fetch (or multiple of them) in the service worker to be dependent on the main thread |
| 15:14 | <JakeA> | fetchEvent.request gives details on the request the browser would make if the service worker wasn't there. It includes the abort signal. You may want to make a different request, but one that's 'inspired' by the original request. Eg use some of the same headers, search string etc etc. One of the things you probably want to copy is any intent to abort. |
| 15:21 | <smaug____> | JakeA: so what if the original request is aborted or you end up using same signal with many fetch calls |
| 15:21 | <smaug____> | I think I'm missing something in this expected pattern |
| 15:21 | <JakeA> | smaug____: using the same signal with many fetches is fine if they're related https://developers.google.com/web/updates/2017/09/abortable-fetch#one_signal_many_fetches |
| 15:23 | <smaug____> | JakeA: signal says it is aborted |
| 15:23 | <smaug____> | but it is just one of the fetches |
| 15:24 | <smaug____> | I guess you're saying that if one is interested in the case when any of the fetches in a group fails, then this works fine |
| 15:25 | <JakeA> | smaug____: fetchStory() is an operation that may involve n fetches. Aborting that operation will involve aborting any of those active fetches, and avoiding any additional ones. |
| 15:28 | <smaug____> | hmm, still missing something :) I would understand this if signal (should be then called something else) was abortable, and calling abort() on it would abort all the fetch and then abort event would be dispatched. But I guess the controller is now somewhere else, hidden |
| 15:35 | <JakeA> | smaug____: So, I give you a buzzer, and tell you to do star jumps until the buzzer buzzes. I, the owner of the buzzer, know the special code to emit to make the buzzer buzz. The signal is the buzzer. |
| 15:36 | <JakeA> | You can't make the buzzer buzz. It's my buzzer. |
| 15:36 | <JakeA> | You're holding it, so you can react to it buzzing. |
| 15:37 | <smaug____> | And why we want this pattern? |
| 15:37 | wanderview | wonders what is going on here... |
| 15:38 | <smaug____> | anyhow, sounds like I should read all the relevant discussions which has lead to this |
| 15:38 | wanderview | reads backscroll... |
| 15:38 | <smaug____> | wanderview: nothing too useful. I'm not being familiar with various reasoning around service worker related API design |
| 15:39 | <smaug____> | definitely an area I should stay away :) |
| 15:39 | <JakeA> | smaug____: this isn't a service worker API |
| 15:39 | <JakeA> | smaug____: Other languages have similar things https://msdn.microsoft.com/en-us/library/system.threading.cancellationtoken(v=vs.110).aspx#Anchor_6 |
| 15:40 | <wanderview> | smaug____: I think its just separation of concerns... separate interfaces for "ability react to the abort" and "ability to trigger the abort" |
| 15:41 | <wanderview> | smaug____: some people really wanted this and I think it made some things cleaner to integrate with fetch, streams, and service worker |
| 15:41 | <wanderview> | smaug____: but fetch abort was a massive bikeshed fest... honestly I accept anything JakeA/annevk/Domenic were able to get consensus on just to have the capability |
| 15:43 | <smaug____> | ok. And yeah, I'm not proposing any changes since the ship has sailed, as I said. Occasionally it would be just nice to understand the reasoning. |
| 15:44 | <JakeA> | smaug____: it's entirely possible there's a better pattern that wasn't considered, as with everything |
| 15:44 | <JakeA> | do you have one in mind? |
| 15:45 | <smaug____> | not sure it is even worth to think about that now. |
| 15:45 | <smaug____> | (random note, I wish more people would have commented microtasks when they were introduced. Perhaps we would have found some better idea.) |
| 15:47 | <wanderview> | its also easier to combine separate interfaces into a single object (put abort() on signal) then it is to split things in the future... so it seemed safer to start with this |
| 15:47 | <wanderview> | maybe we can make a simplified abort interface in the future |
| 16:10 | <annevk> | Domenic: https://searchfox.org/mozilla-central/source/dom/html/HTMLInputElement.cpp#180 already seems like a different feature |
| 16:10 | <annevk> | Domenic: and it's not even behind a flag |
| 16:10 | <annevk> | smaug____: ^^ |
| 16:10 | annevk | wonders if that inputmode thing impl is hooked up to something |
| 16:11 | <smaug____> | I thought it is used on android, but I could be wrong |
| 16:12 | <smaug____> | I think I'm wrong |
| 16:25 | <annevk> | othermaciej: was Event's having cancel() a typo? Firefox does not have that method at least |
| 16:25 | <othermaciej> | IT was, I meant stopPropagation(), as Jake correctly inferred |
| 16:26 | <othermaciej> | Just so I can avoid asking more basic questions in the issue, where in the event dispatch process is the microtask queue drained? |
| 16:26 | <othermaciej> | Is it after every individual event listener gets called? |
| 16:27 | <annevk> | othermaciej: it depends on whether the JavaScript stack is empty |
| 16:27 | <annevk> | othermaciej: and yes, that is the point |
| 16:27 | <annevk> | othermaciej: that invokes an algorithm defined in IDL that integrates with HTML that drains the microtask queue if the JavaScript stack is empty |
| 16:27 | <JakeA> | othermaciej: https://dom.spec.whatwg.org/#concept-event-listener-inner-invoke step 7, to https://heycam.github.io/webidl/#call-a-user-objects-operation step 16.2, to https://html.spec.whatwg.org/multipage/webappapis.html#clean-up-after-running-script |
| 16:28 | <othermaciej> | making the timing of event delivery depend on whether the JavaScript stack is empty seems bad |
| 16:28 | <annevk> | smaug____ should know why microtasks work this way |
| 16:28 | <annevk> | It's probably about time we start adding note around it |
| 16:29 | <othermaciej> | besides dispatching custom events by hand, I'm pretty sure there are Web Platform APIs that will synchronously dispatch an event from a method called from JavaScript |
| 16:29 | <othermaciej> | for example element.click() |
| 16:29 | <othermaciej> | or element.focus() |
| 16:29 | <othermaciej> | This seems like a big weakness of the Observable proposal, yet is required to get the nice integration with async/await |
| 16:31 | <JakeA> | abortController.abort() causes the "abort" event to fire on the related signal without a turn of the event loop too |
| 16:31 | <smaug____> | The idea with microtask behaving that way was to let event listeners work without necessarily affecting each others. So that when a listener is called, all the mutation observer callbacks would have been called already. |
| 16:32 | <smaug____> | Note, Microtasks were designed way before all the Promise stuf |
| 16:32 | <JakeA> | That behaviour enables IDB to be wrapped in promises, so I'm a fan |
| 16:32 | <smaug____> | or perhaps there were ideas of Promises or Futures, but their scheduling definitely wasn't based on microtasks initially |
| 16:32 | <othermaciej> | I am definitely not questioning the timing of microtasks |
| 16:33 | <othermaciej> | I just wanted to understand what it is |
| 16:33 | <othermaciej> | Since this Observable proposal for events depends on it |
| 16:33 | <smaug____> | (I have started to question the timing of microtasks because devs seem to misuse them badly by creating long promise chains, and that causes jank) |
| 16:34 | <smaug____> | (but as I said, microtasks were not designed with Promise kind of thing in mind. ) |
| 16:35 | <JakeA> | (I only mention the IDB thing because that's when I 'discovered' that microtasks happen between event callbacks in stack-empty cases) |
| 17:51 | <Domenic> | MikeSmith: I don't see any changes at https://github.com/validator/validator/commits/master, but the validator in the CI build for HTML started reporting the focus-within etc. CSS errors again. Any chance you pushed some changes to the .tgz or something that might have regressed? |
| 17:53 | <MikeSmith> | hmm could be |
| 17:53 | MikeSmith | looks |
| 18:24 | <MikeSmith> | Domenic: fixed |
| 18:24 | <MikeSmith> | sorry about that |
| 18:24 | <Domenic> | Phew. What happened? |
| 18:24 | <MikeSmith> | the formatting of the messages changed |
| 18:24 | <MikeSmith> | I added “ and ” around the literals in the messages |
| 18:25 | <MikeSmith> | > Unknown pseudo-element or pseudo-class “:focus-within” |
| 18:25 | <MikeSmith> | > “leader(". ")” is not a “content” value |
| 18:25 | <MikeSmith> | those were unquoted before |
| 18:25 | <MikeSmith> | the filter expression didn’t account for the quotes |
| 18:26 | <MikeSmith> | I’ll add some tests |
| 18:26 | <MikeSmith> | so that I don’t regress it again |
| 18:26 | <Domenic> | \o/ |
| 22:10 | <annevk> | jgraham: https://github.com/whatwg/meta/issues/58 |
| 22:19 | <jgraham> | annevk: Thanks |
| 22:29 | <muteki> | someone explained to me CORS as follow: "Lets make it easier. badsite.com sends a JS asset to your browser and in that JS it tells your browser to request bank.com/send-money-to-the-bad-guys, bank.com is the one who sets the headers that allow requests to come from badsite.com" |
| 22:29 | <muteki> | but is it true if badsite is not aware by bank.com, the request send-money-to-the-bad-guys still be issued by the browser and processed by bank.com, it's just the response not being processed by the browser? |
| 22:40 | <TimothyGu> | muteki: how does badsite.com send a JS asset in the first place? |
| 22:42 | <muteki> | good question, I didn't ask, but I guess probably the user wander to that page accidentally? |
| 22:42 | <muteki> | I was basically asking some general concepts behind CORS and that's the response I got |
| 22:57 | <annevk> | muteki: did you read through the examples in the Fetch Standard? |
| 22:58 | <muteki> | annevk: you meant 3.2.6 in https://fetch.spec.whatwg.org/#cors-protocol ? |
| 23:00 | <muteki> | I think I understand how it works, but I am just trying to understand the rationale behind it and what does it use to protect against... especially the example mentioned by others about bank.com, seems to be not quite fitting the actual CORS protocol |
| 23:00 | <annevk> | muteki: I have to admit I don’t quite follow that example either |
| 23:01 | <muteki> | wondering maybe that example (badsite.com/bank.com) is not quite accurate |
| 23:01 | <annevk> | muteki: CORS in principle does not protect; it enables sharing of otherwise protected resources |
| 23:02 | <annevk> | muteki: the reason those resources are protected is because they might contain confidential information about the user or the user’s local network |
| 23:02 | <muteki> | annevk: I think that makes sense, because the resource can be accessed regardless using curl or other method, but it's to workaround (or provide way to add exception) to the same origin policy enforced by the browser, am I correct? |
| 23:03 | <annevk> | muteki: you cannot always fetch it with curl |
| 23:03 | <annevk> | muteki: consider a fetch with the cookies from the user |
| 23:04 | <annevk> | muteki: or to a local IP or IP-authenticated server |
| 23:04 | <annevk> | muteki: https://annevankesteren.nl/2015/02/same-origin-policy might also help |
| 23:04 | <muteki> | thanks, let me read through that |
| 23:40 | <muteki> | annevk: thanks for the link, so here is what I gathered after reading your blog plus the example people gave me, please let me know if I am missing anything... it sounds like his badsite.com is untrusted.example as described in your blog and bank.com is intranet.example. so, without CORS, bad JS hosting by untrusted.example can ask user's browser to access resource on intranet.example. but even with |
| 23:41 | <muteki> | CORS, untrusted.example can still serve bad JS to browser, and browser will send request to intranet.example and response will be sent but not process by browser.. and if we want to prevent request (or full power request in your blog) processed by intranet, we need preflight requests for further protection. am I correct? |