| 06:17 | <ondras> | Domenic: interested in the `queueMicrotask` -- what is the expected purpose/usecase for this kind of scheduling? |
| 06:20 | <annevk> | ondras: https://github.com/w3ctag/design-reviews/issues/294#issuecomment-408258727 might help |
| 06:22 | <ondras> | annevk: well that mostly explains why the new api is better than resolve.then |
| 06:22 | <ondras> | annevk: but I somewhat fail to see the use case for both |
| 11:33 | <annevk> | ondras: https://github.com/whatwg/html/pull/3873 might also help |
| 11:33 | <annevk> | (again, might 😊) |
| 11:35 | <ondras> | annevk: thanks! this probably has all I need to educate myself :) |
| 11:37 | <ondras> | in particular, the second example is something I can relate to. the first one looks pretty weird to me, but whatevs. |
| 12:47 | <benjamingr_> | Hey, has there been talk of a setTimeout variant that returns promises? I'm asking for a JavaScript API and I'd just prefer to implement something with a spec than something without. |
| 12:47 | <benjamingr_> | (Also, a setInterval that returns async iterators) |
| 12:47 | <annevk> | benjamingr_: just talk afaik |
| 12:48 | <annevk> | benjamingr_: don't think there's even an issue for it |
| 12:48 | <benjamingr_> | Can/should I open one? |
| 12:48 | <annevk> | benjamingr_: sure, against whatwg/html |
| 12:49 | <wanderview> | `new Promise(r => setTimeout(r, 5000))` is a bit annoying, but pretty short already |
| 12:49 | <annevk> | that's also true |
| 12:49 | <benjamingr_> | wanderview: one possible con for it is that there is already a way to do it and it wouldn't add a capability, on the other hand you'd be surprised at how wrong people get that simple one liner |
| 12:50 | <wanderview> | what would be interesting is if a "modern" timeout API could not only include promise support, but also maybe remove legacy clamping behavior |
| 12:50 | <wanderview> | but adding more stuff also makes any proposal more likely to fail |
| 12:50 | <wanderview> | maybe I should just drink my coffee |
| 12:51 | <benjamingr_> | lol, yeah, I don't think that's something we'll be able to do |
| 12:51 | <wanderview> | no? |
| 12:53 | <benjamingr_> | By the way and on a completley unrelated note: is there any eta for streaming fetch in firefox wanderview? I saw there is some interesting work involving it and wanted to offer to be a guinea pig since we are pretty heavy consumers of it on chrome. (And by all means do feel free to tell me that the current ETA is 'sometime' and it's not a priority) |
| 12:53 | <benjamingr_> | Re: timeout without clamping - we've discussed it a bunch in Node - I don't think there was enough interest but maybe I'm remembering it wrong. |
| 12:53 | <annevk> | benjamingr_: there's dom.streams.enabled but I'm not sure if that covers fetch() |
| 12:53 | <wanderview> | benjamingr_: there are prefs you can enable to test today (and for like the last year) |
| 12:54 | <annevk> | there's also javascript.options.streams, hmmm |
| 12:54 | <wanderview> | benjamingr_: a thorny cross global issue has kept it from shipping, but in theory thats finally being reviewed now'ish |
| 12:54 | <benjamingr_> | That does cover `fetch` yeah, I've been testing that - I'm sort of the person in my company who cares about firefox users' UX |
| 12:54 | <wanderview> | annevk: yea, you need both those prefs |
| 12:55 | <annevk> | benjamingr_: <3 |
| 12:55 | <benjamingr_> | Yeah, it works for us with those perfs - works pretty well too. Firefox WebRTC has more (and better) connections than Chrome at the moment but it's losing in UX on our infrastructure without streaming fetch and wins with it - it's more of an office bet than anything. |
| 12:57 | <wanderview> | benjamingr_: posting your expected wins in the stream bug may help folks prioritize it |
| 12:57 | <wanderview> | or maybe annevk can just relay the information |
| 12:58 | <jgraham> | Seeing it from someone developing an actual product seems potentially useful |
| 12:59 | <benjamingr_> | Well, we're building a p2p streaming platform on top of WebRTC and hls/mpeg-dash - streaming fetch means we can share segments before we finished downloading them which really improves UX on congested networks - especially in places like southeast Asia and Latin America. We see streaming fetch making the biggest difference there. |
| 12:59 | <wanderview> | benjamingr_: this is the bug if you want to chime in with some actual data, etc: https://bugzilla.mozilla.org/show_bug.cgi?id=1389628 |
| 13:01 | <benjamingr_> | Thanks, I saw that - I'm usually afraid I'll just be annoying in these bugs - I dislike it when people show up and "demand" work on something myself so I usually try not to do it myself. I only bugged you about it now since I saw recent activity and we were already talking. |
| 13:02 | <wanderview> | I understand, but I would look at it more as sharing real world data the browser vendor is probably lacking... |
| 13:05 | <benjamingr_> | https://github.com/whatwg/html/issues/3875 hope this is appropriate, feel free to tell me to edit/fix it in some way |
| 14:48 | <annevk> | Ugh: https://bugzilla.mozilla.org/show_bug.cgi?id=1477286 |
| 14:48 | <annevk> | I thought we only had synthetic click events and were on track to remove synthetic submit events causing action? |
| 19:53 | <Domenic> | Oh no :( |
| 23:07 | <rniwa> | Domenic: yt? |