| 07:45 | <hsivonen> | I take it that postMessage() to self in order not to block the event loop without waiting on a timeout is obsolete with promises |
| 07:48 | <hsivonen> | or is it? what's the right way to return a promise that does nothing but let the event loop turn and then resolve? |
| 07:49 | <Methodist> | Hey |
| 07:50 | <hsivonen> | oh, it's always on microtask queue |
| 08:29 | <hsivonen> | is there a good blackbox function in JS that just returns its argument but that the compiler is guaranteed not to optimize out? |
| 08:30 | <hsivonen> | i.e. something that can force the lack of optimizing out operations being benchmarked |
| 09:10 | <MikeSmith> | hsivonen: caitp might have a good answer to that, if she’s around |
| 09:50 | <jpdevries> | Does anyone know if we may see <datalist> support <optgroup>? My understand of the spec is it doesn't really say if it should either way. |
| 09:51 | <jpdevries> | Nevermind. Found something promising 🤞https://www.w3.org/TR/html5/forms.html#the-option-element |
| 09:51 | <jpdevries> | |
| 09:55 | jpdevries | read that wrong, mistook option section for optgroup section 😢 |
| 12:00 | <tobie> | can someone enlighten me on the relationship between event firing and task sources? |
| 12:01 | <tobie> | looking for something as basic as: "they're completely orthogonal" or "one implies the other" |
| 12:05 | <jgraham> | When you queue an event to be fired it is put into a task source. At some point the event loop spins, the event is grabbed from the task source, and it is dispatched |
| 12:06 | <caitp> | hsivonen: in v8, the legacy pipeline was very happy to not opt or inline anything if all kinds of stuff was used |
| 12:09 | <caitp> | the new pipeline will skip some but not all optimizations if you do certain things, so probably the best you can do is %NeverOptimizeFunction(func) |
| 12:10 | <caitp> | there might be some better |
| 12:12 | <tobie> | jgraham: right. But can you just fire an event without queueing it? |
| 12:13 | <tobie> | jgraham: if so, what's the distinction between these two things and when should you choose one over the other? |
| 12:18 | <jgraham> | tobie: Yeah, but that means it dispatches synchronously so if you have (pseduocode) <script>fooRan = false; addEventListener("foo", () fooRan = true); fireEvent("foo"); /* now foo handlers run */ assert(fooRan, true)</script> |
| 12:19 | <tobie> | jgraham: right. How do we decide what behavior to go for? |
| 12:19 | <jgraham> | tobie: Firing synchronous events is very rare |
| 12:21 | <tobie> | jgraham: is there a document that explains which one should be used when |
| 12:21 | <jgraham> | I think it's async always except if there's some legacy |
| 12:21 | <tobie> | jgraham: oh |
| 12:21 | <jgraham> | But idk if that's written down somewhere, and I could be wrong in some case I haven't thought of |
| 12:22 | <tobie> | jgraham: it's about firing event when a new sensor reading is received. |
| 12:23 | <smaug> | hmm, firing sync events rare? click(), and focus() etc cause various sync events. Mutation Events are sync... But yes, legacy mostly |
| 12:23 | <smaug> | tobie: if that receiving is already async, then dispatching event sync is probably ok |
| 12:24 | <tobie> | smaug: it is async, yes. It's a shared memory buffer that's updated |
| 12:24 | <jgraham> | As part of a task? |
| 12:24 | <smaug> | but better to do the sync dispatch at the end of some algorithm, since event handling may change the state of the world |
| 12:24 | <jgraham> | Like if there's already a task on the stack then you can fire events sync |
| 12:25 | <jgraham> | But otherwise one typically queues a task specifically to fire them |
| 12:26 | <tobie> | So the part where the buffer is updated is totally hand-wavy in the spec for now |
| 12:26 | <tobie> | So it isn't clearly specified as happening within a task. |
| 12:27 | <tobie> | Is what you're saying that this happens within a task whether or not I've specifically written it down? |
| 12:28 | <tobie> | (This is probably a stupid question but I'm not familiar with how to spec things that happen at the boundary with the underlying C++ code) |
| 12:28 | <tobie> | ^ smaug, jgraham |
| 12:35 | <smaug> | hmm, that is unclear in the specs |
| 12:35 | <smaug> | I'd say |
| 12:35 | <smaug> | when data is coming from outside |
| 12:35 | <smaug> | but implicitly it needs to be in some task source |
| 12:42 | <tobie> | smaug: maybe I should rephrase this differently. Is there anything that can happen outside of a task source? |
| 12:42 | <jgraham> | tobie: Sure |
| 12:42 | <jgraham> | But it's bad :) |
| 12:43 | <jgraham> | Like if you update data in the background then in theory something like (very pseudoCode) <script>getSensorData("foo") == getSensorData("foo")</script> doesn't hold |
| 12:45 | <jgraham> | Typically the platform tries to expose consistent state to each script, but that isn't always the case. |
| 12:48 | <tobie> | ok. I think that makes sense. |
| 12:48 | <tobie> | Thanks. |
| 12:51 | <tobie> | smaug, jgraham: would either of you have pointers of other specs doing something similar and that would have gotten this right so I could copy it? |
| 12:52 | <tobie> | (off the top of your head) |
| 12:53 | <jgraham> | Not off the top of my head |
| 13:12 | <tobie> | alright thanks for the explanation, folks. |
| 18:45 | <Domenic> | tobie: not sure i fully understand the scenario but i would imagine sensor reading happens off-main-thread. in which case you must queue a task to go back to the main thread in order to fire the event |
| 18:45 | <Domenic> | You can't fire an event from off-main-thread (i.e. from "in parallel" sections) |
| 18:49 | <tobie> | Domenic: so what happens is that the underlying layer updates a shared memory buffer whenever there's a new sensor reading. |
| 18:52 | <tobie> | Domenic: on the JS side this causes an event to be fired. and the sensor.value attribute getter now return the value from that shared buffer (or a copy of it stored in a private var, this is still in flux) |
| 18:54 | <Domenic> | "causes an event to be fired" how? |
| 18:54 | <Domenic> | Does the spec actually speak in terms of shared memory buffers? |
| 18:55 | <tobie> | Domenic: no. It's a infra map |
| 18:55 | <tobie> | *an |
| 18:55 | <Domenic> | OK. But the updating happens "in parallel" I'd assume |
| 18:55 | <tobie> | Domenic: yes. |
| 18:55 | <Domenic> | Great. So then yeah, you need to queue a task to fire the event. |
| 18:57 | <tobie> | So: in parallel, set map[value] to x, then queue a task to fire an event. |
| 18:57 | <Domenic> | sounds perfect :) |
| 18:58 | <tobie> | Domenic: thanks a bunch, it the "in parallel, update the map" bit I was missing to make sense of it all. |
| 18:58 | <tobie> | *it's |
| 18:59 | <tobie> | Domenic: if the map is updated in parallel, an instances have a getter to the map value, doesn't that still risk to cause concurrency issues? |
| 19:00 | <Domenic> | It does tingle my danger sense... Not sure about if there's a concrete problem though... |
| 19:00 | <Domenic> | Not sure I understand the dangers there very well myself, to be honest |
| 19:01 | <Domenic> | I think it might be OK if it's hidden behind a getter? |
| 19:01 | <Domenic> | Because the worst that can happen is that x.value !== x.value |
| 19:01 | <Domenic> | But that's explainable in terms of .value being a getter |
| 19:01 | <Domenic> | I guess it's still unexpected |
| 19:01 | <Domenic> | If you want to avoid that you can update the map in the queued task too |
| 19:02 | <Domenic> | So it's like: in parallel, wait for a change. When the change happens, queue a task to update the map and fire an event |
| 19:02 | <tobie> | Domenic: ^ this. |
| 19:02 | <tobie> | Awesome. |
| 19:13 | <tobie> | Domenic: one last question. The spec was designed with it's own sensor queue that could be disabled for security reasons (e.g. when focus was lost). Does that make sense, and if so, do we need a queue per instance, per browsing context? per what? |
| 19:13 | <tobie> | * its |
| 19:15 | <jyasskin> | tobie: This doesn't answer your question, but do you have a good reference for "when focus is lost"? NFC and WebAuthn want it, and I think it doesn't exist yet in HTML. |
| 19:16 | <jyasskin> | tobie: To answer your question, https://webbluetoothcg.github.io/web-bluetooth/#notification-events may be a similar situation? |
| 19:17 | <tobie> | jyasskin: putting the kids to bed. But yeah that seems what I'm looking for. |
| 19:31 | <Domenic> | tobie: I am pretty sure event queues are per event loop |
| 19:33 | <tobie> | Domenic: maybe it makes more sense to have a per browsing context global flag for stopping the events for security reasons rather than piggy-backing on top of the event loop. |
| 19:34 | <Domenic> | Hmm yeah |
| 19:35 | <jyasskin> | i.e. you'd post a task that says "if the flag is set, return", right? |
| 19:37 | <Domenic> | It depends on if you want ignore-when-unfocused or add-to-backlog-when-unfocused behavior... the latter seems tricky. |
| 19:40 | <jyasskin> | Yeah, "if the flag is set, do the right thing. Otherwise the other right thing." |
| 19:43 | <tobie> | Domenic: ignore-when-unfocused |
| 19:43 | <Domenic> | Then yeah jyasskin's version sounds perfect |
| 19:43 | <tobie> | jyasskin: cool. |
| 19:45 | <tobie> | jyasskin: so yes, this seems like a very similar situation https://webbluetoothcg.github.io/web-bluetooth/#notification-events |
| 19:46 | <tobie> | jyasskin: wrt "when focus is lost event" do you know of an open issue against HTML? |
| 19:51 | <tobie> | jyasskin: I couldn't find anything after a cursory look. Could you point me to where in WebBluetooth this is needed? Also if you already have an open issue in your repo on this? Like that I can file a bug an reference all the things |
| 20:12 | <annevk> | Do not update state without a task |
| 21:10 | <tobie> | annevk: well, that probably should be printed on a whatwg t-shirt? |
| 22:26 | <jyasskin> | tobie: Sorry, had to go home to watch Max. I don't know of an existing issue against HTML. NFC tries to use it in https://w3c.github.io/web-nfc/#handling-window-visibility-and-focus, and WebAuthn has an issue for it in https://github.com/w3c/webauthn/issues/316 |
| 22:28 | <tobie> | jyasskin: looks like you just found the issue. :) |