| 07:19 | <tobie> | Mmm. Still confused about when to queue a task to do something vs. just doing something. |
| 07:20 | <tobie> | The other day, annevk wrote: "Do not update state without a task" but that doesn't really work for example for an object's state. |
| 07:21 | <tobie> | For example, in https://w3c.github.io/sensors/#sensor-start |
| 07:22 | <annevk> | tobie: it's fine to update state in response to method calls too |
| 07:22 | <tobie> | If you sensor.start() is called twice in the same event turn, and sensor.[[state]] is changed in a task, than the guard it's supposed to provide no longer works. |
| 07:23 | <tobie> | annevk: Ah! |
| 07:23 | <annevk> | tobie: use a task was meant for "async" changes |
| 07:24 | <tobie> | async as "in parallel" |
| 07:24 | <annevk> | tobie: yeah, or later point in time |
| 07:25 | <tobie> | annevk: ok, so basically the idea is to protect JS's single-threaded nature when faced with external interactions, right? |
| 07:26 | <annevk> | tobie: yeah, ensure obj.x === obj.x |
| 07:26 | <tobie> | annevk: cool |
| 07:27 | <tobie> | annevk: what about the "queue a task" to fire an event. I'm seeing it used in places, but there's no consistency |
| 07:42 | <annevk> | tobie: generally good, depends on the trigger though |
| 07:46 | <tobie> | annevk: well, they're either coming from such an async event |
| 07:47 | <tobie> | (so they're effectively already happening from within a queued task) |
| 07:48 | <tobie> | annevk: or from other platform hooks (e.g. asynchronously checking for the permission state in the permission API) |
| 07:51 | <tobie> | annevk: I guess a subsidiary question is: what if the event isn't queue and its handler throws? Will that affect the rest of my algorithm? |
| 08:36 | <foolip> | annevk: thanks, I'll not block on your feedback for fullscreen changes until you're back and recovered from inbox hangover then |
| 10:07 | <annevk> | tobie: no |
| 12:21 | <hsivonen> | relevant to this channel in reference to the U+FFFD discussion the other day: https://hsivonen.fi/broken-utf-8/ |
| 12:25 | <hsivonen> | annevk: AFAICT, TextDecoder doesn't make a copy of the input. The binding layer probably copies the output. TextEncoding makes a copy of the output. The binding layer probably copies the input. |
| 12:25 | <hsivonen> | annevk: do you have an example of a performance-sensitive real-world use of either? |
| 14:48 | <yoav> | Domenic: if you're around I'd love your opinion on the best way to tackle https://github.com/whatwg/html/pull/2588#issuecomment-305017268 |
| 14:54 | <yoav> | also, as annevk is OOO, I'd love to land https://github.com/whatwg/fetch/pull/549 before he returns, so maybe you could review? |
| 16:12 | <Domenic> | yoav: still catching up on backlog, will hopefully get to those today or tomorrow |
| 16:13 | <yoav> | ok, thanks! :) |
| 16:13 | <Domenic> | hsivonen: we have some internal Google person emailing us about TextEncoder/TextDecoder not being fast enough in Chrome for some large web site, let me see if they've commented anywhere publicly... |
| 16:14 | <Domenic> | Not a lot of detail on the actual use case, but they filed https://bugs.chromium.org/p/chromium/issues/detail?id=689753 |
| 17:52 | <Domenic> | Edge has started implementing the Encoding API: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6558040-support-the-encoding-api?tracking_code=b4e7100132add183f16a703b4d089525 /cc annevk |
| 17:56 | <Domenic> | Can anyone confirm whether or not Safari 10.1 ships it? The internet is not helpful. |
| 18:11 | <hsivonen> | annevk, Domenic: IIRC, in Gecko, the overhead from testing encoding_rs within TextDecoder was very large compared to testing it in a non-browser test harness without any binding layers involved |
| 18:21 | <annevk> | Domenic: retweeted from @encodings |
| 21:04 | <GPHemsley> | If url’s scheme is a special scheme and buffer is not, then return. |
| 21:04 | <GPHemsley> | If url’s scheme is not a special scheme and buffer is, then return. |
| 21:04 | <GPHemsley> | (from URL) |
| 21:04 | <GPHemsley> | is that checking whether buffer is a special scheme? |
| 21:15 | <Domenic> | GPHemsley: pretty sure yes... let's see... |
| 21:15 | <Domenic> | GPHemsley: yeah, pretty sure. That's not super-clear though. |
| 21:15 | <GPHemsley> | cool, thanks |
| 21:15 | <GPHemsley> | I'll file an issue |
| 21:19 | <GPHemsley> | https://github.com/whatwg/url/issues/315 |
| 22:13 | <weinig> | tobie: Do you happen to know why the legacy platform object [[Set]] algorithm (https://heycam.github.io/webidl/#legacy-platform-object-set) in step 1.2 stipulates that “P is not an array index property name” |
| 22:14 | <weinig> | tobie: my reading of it, and I very well may be missing something here, is that means that an object with a named property getter, but no indexed property getter will not support indexed properties |
| 22:14 | <weinig> | e.g window.localStorage[7] = “foo” |
| 22:15 | <tobie> | weinig: I remember stumbling on exactly the same issue a while back |
| 22:15 | <tobie> | weinig: and figuring out how/why I was reading the algo wrong. |
| 22:15 | <weinig> | heh |
| 22:16 | <weinig> | tobie: does it have something to do with the “If O and Receiver are the same object” part, cause that I have not looked into yet |
| 22:19 | <weinig> | tobie: if you remember what you figured out, let me know ;) |
| 22:21 | <tobie> | weinig: I think it just means that if your interface supports both indexed and named props, then, indexed props take precedence |
| 22:21 | <Domenic> | Hmm... it seems to be saying if you support named properties, "1" does not count as a named property |
| 22:22 | <Domenic> | which is believable |
| 22:22 | <tobie> | Yeah that's another way of looking at it. |
| 22:25 | <tobie> | Basically that if you support both, than [[Set]]ing "1" will invoke the indexed prop setter and not both the indexed prop and the named prop setter as it would if the "P is not an array index property name" was missing from step 1.2 |
| 22:25 | <tobie> | *then |
| 22:25 | <tobie> | (sorry for the horrendous grammar) |
| 22:27 | <weinig> | I think that means localStorage, as currently spec’d, doesn’t support [[Set]]ing “1”, but browsers seem to allow that |
| 22:29 | <weinig> | e.g window.localStorage[7] = “foo” |
| 22:29 | <Domenic> | Oooh OK, that's not great |
| 22:30 | <weinig> | https://html.spec.whatwg.org/multipage/webstorage.html#the-storage-interface (for reference) |
| 22:30 | <Domenic> | weinig: can you file a bug so we can get bz to check that we're not missing something? Otherwise yeah we should fix this. |
| 22:30 | <weinig> | yup |
| 22:30 | <Domenic> | Wow who knew... localStorage.key(2) |
| 22:31 | <Domenic> | What a weird interface, it's clearly trying to be indexed, but not quite |
| 22:36 | <tobie> | Domenic: mmm. Do we just want to change 1.2 to (P is not an array index property name or O does not supports indexed properties)? |
| 22:37 | <tobie> | Or am I misunderstanding the issue? |
| 22:37 | <Domenic> | tobie: I think we just want to remove "P is not an array index property name" from 1.2 |
| 22:40 | <weinig> | for the record, that is what makes sense to me too |
| 22:40 | <weinig> | and it’s closer to what [[DefineOwnProperty]] does |
| 22:41 | <weinig> | though [[DefineOwnProperty]] also has a unforgeables check |
| 22:41 | <KiChjang> | omg, i did not know that the HTML spec had time travel laid out for us |
| 22:41 | <weinig> | and differs based on [OverrideBuiltins] |
| 22:42 | <weinig> | I feel like I’m missing something in this [[set]] business |
| 22:42 | <tobie> | Domenic: well, we'd set the prop twice in those cases. |
| 22:43 | <Domenic> | tobie: Nah, `return true` in 1.1.2, right? |
| 22:44 | <weinig> | While I have your attention, should window.EventListener exist as per (https://dom.spec.whatwg.org/#callbackdef-eventlistener) |
| 22:44 | <tobie> | Domenic: you're right. |
| 22:45 | <tobie> | So yeah, that seems redundant and broken. |
| 22:45 | <Domenic> | weinig: right, I answered that after you left. No, per https://heycam.github.io/webidl/#interface-object "The interface object for a given ******non-callback***** interface I with..." |
| 22:45 | <Domenic> | tobie: I mean, the current spec seems somewhat reasonable, e.g. if could be an attempt to allow adding indexed setters later without breaking code. But it sounds like it's not what people implemented. |
| 22:45 | <Domenic> | Unless we are missing something |
| 22:46 | <tobie> | Oh, hadn't thought of this future proof option. |
| 22:46 | <weinig> | Domenic: then what’s the deal with https://dom.spec.whatwg.org/#interface-nodefilter |
| 22:47 | <Domenic> | What is the deal indeed... I used to know this... |
| 22:47 | <tobie> | weinig: it's the only one of the lot with constants, no? |
| 22:47 | <Domenic> | Ah yes: https://heycam.github.io/webidl/#legacy-callback-interface-object |
| 22:47 | <Domenic> | "and on which constants are defined" |
| 22:47 | <weinig> | “ on which constants are defined, a corresponding property must exist on the ECMAScript environment’s global object" |
| 22:47 | <weinig> | !! |
| 22:47 | <weinig> | boom, thanks |
| 22:48 | <weinig> | mystery solved :) |
| 22:48 | <weinig> | back to [[Set]], I’m betting the way this works, it expects to go into OrdinarySet which will end up calling [[DefineOwnProperty]] |
| 22:48 | <weinig> | but I don’t know how |
| 22:49 | <Domenic> | Oh, I see... |
| 22:50 | <weinig> | I do like that it says “steps 3-11 of the default [[Set]] internal method”, but the default [[Set]] internal method only has 1 step :) |
| 22:50 | <Domenic> | weinig: Oh, I think that's how it works |
| 22:50 | <Domenic> | lol yes that is error prone |
| 22:50 | <Domenic> | we should refactor ES to fix that somehow |
| 22:51 | <Domenic> | But yes, I think [[Set]] will fall through to calling [[DefineOwnProperty]] which will go to https://heycam.github.io/webidl/#legacy-platform-object-defineownproperty step 2.2.2 |
| 22:52 | <Domenic> | So why do these shortcut steps exist in [[Set]] at all? I guess I could think up edge cases where it would matter, bleh. |
| 22:52 | <weinig> | Domenic: I’m un clear on what step 1 is for then, but I don’t really know what the Receiver is, so I will go bother some JSC folks into telling me instead of looking it up |
| 22:52 | <weinig> | Domenic: exactly |
| 22:52 | <weinig> | anyway, thanks! |
| 22:52 | <Domenic> | So O and the receiver will not be the same when a proxy is involved |
| 22:53 | <weinig> | Domenic: ah |
| 22:53 | <tobie> | weinig: can you file issues for both these things (weird [[Set]] behavior for "1", and algo referring now-removed steps) so they don't fall through the cracks? |
| 22:53 | <weinig> | tobie: sure, I did the first already |
| 22:54 | <tobie> | weinig: thanks! |
| 22:54 | tobie | is hitting the sack. It's late here. |
| 22:55 | <Domenic> | tobie: weinig: I think the removed-steps one is https://github.com/heycam/webidl/issues/201 |
| 22:55 | <weinig> | Domenic: indeed |
| 22:55 | weinig | enjoys that tobie filed it |
| 22:55 | <weinig> | I’m off too |
| 22:56 | <tobie> | Arg!! |
| 22:59 | <tobie> | The funniest part is there was this little voice at the back of my head saying: "this sounds vaguely familiar, we must have done it already in another part of the spec. Great I'll just need to look it up to see how we fixed this. This is going to be easy." |