| 01:19 | <TimothyGu> | annevk: is https://github.com/web-platform-tests/wpt/blob/master/xhr/open-url-multi-window-4.htm a legit test? The referenced pull request was closed without being merged, no browser other than Safari passes it, and it times out (like Firefox) when I fix https://crbug.com/879620 |
| 01:21 | <TimothyGu> | In particular I don't think the test for `error` event is kosher, as discard a Document aborts the document, and should only fire `abort` event |
| 01:24 | <TimothyGu> | (by "it" times out, I mean Chrome times out when I fix the linked bug, which is what Firefox currently does) |
| 03:15 | <annevk> | TimothyGu: some xhr tests are really old and could prolly use a fresh look |
| 03:16 | <annevk> | TimothyGu: I can take look later |
| 03:16 | <TimothyGu> | annevk: that'd be appreciated, thanks |
| 03:29 | <TimothyGu> | annevk: the main issue here seems to be that in Chrome and Firefox, XMLHttpRequest objects in an inactive document go "dead" and will not fire any events, period. not sure if that behavior is spec'd anywhere though |
| 03:41 | <annevk> | TimothyGu: xhr does spec a fully active check iirc |
| 03:41 | <annevk> | TimothyGu: the weird thing is that we don’t have it for similar APIs |
| 03:41 | <TimothyGu> | annevk: it's only in open() though |
| 03:42 | <annevk> | True |
| 03:42 | <TimothyGu> | from the impl side it looks like it should really be in fetch |
| 03:42 | <TimothyGu> | (by impl I mean Blink and probably WebKit and Gecko) |
| 03:43 | <annevk> | And what does the caller get? Network error? |
| 03:43 | <TimothyGu> | probably? |
| 03:44 | <annevk> | Given that’s async it could change over time too |
| 03:44 | <TimothyGu> | either that or an aborted request |
| 03:44 | <annevk> | But I guess we terminate fetches when docs go inactive |
| 03:45 | <annevk> | Fetch groups are still poorly specced unfortunately |
| 03:45 | <TimothyGu> | :( |
| 03:45 | <TimothyGu> | have you looked at the test yet? |
| 03:45 | <TimothyGu> | it's sort-of blocking my work on Chromium making the abort event async |
| 03:46 | <annevk> | Stuck with my phone and a baby; I cannot take a good look for another couple hours |
| 03:46 | <annevk> | I guess I can peek at the source |
| 03:46 | <TimothyGu> | ah. it's not too terribly huge |
| 03:47 | <TimothyGu> | the resources/init.htm file just calls top.init() when loaded, nothing spectacular |
| 03:48 | <TimothyGu> | anyway I'll sleep soon and won't get to this until tomorrow, so feel free to take your time. |
| 03:48 | <annevk> | TimothyGu: so this depends on unspecced stuff |
| 03:49 | <annevk> | TimothyGu: how exactly canceling a fetch group looks |
| 03:50 | <annevk> | TimothyGu: if error events this would make sense, but dunno what would be best and what compat allows for |
| 03:50 | <annevk> | s/looks/functions/ |
| 03:51 | <TimothyGu> | So Safari is the only one that does error events, per wpt.fyi (Edge result is missing though). A reasonable guess is that they only implemented that in order to fix this specific test. |
| 03:54 | <annevk> | Yeah |
| 03:55 | <annevk> | I guess the question is, when a doc goes inactive, how do all fetchy things behave today and does that match what we think is good |
| 03:56 | <annevk> | Not firing events seems weird, but if you want to stop running code in a closed tab makes sense |
| 03:57 | <TimothyGu> | bz would probably be a person to talk to. And also this has implication on salvageability too |
| 03:59 | <annevk> | Yeah |
| 04:00 | <TimothyGu> | anyway, for the purpose of implementing the abort event timing correctly in Chrome, I'll just change the expectation to time out instead of failing |
| 04:17 | <annevk> | sgtm |
| 04:31 | <rniwa> | annevk: yt? |
| 04:36 | <rniwa> | smaug____: yt? |
| 06:33 | <rniwa> | smaug____: ping? |
| 06:45 | <annevk> | rniwa: am now |
| 06:45 | <annevk> | If this is about web components, I haven't gotten around to looking at the latest there yet |
| 06:45 | <rniwa> | annevk: i have: https://github.com/whatwg/dom/issues/685 |
| 06:46 | <rniwa> | annevk: I just wanna know if the current spec's wording is intentional |
| 06:46 | <rniwa> | annevk: or it's just an oversight |
| 06:47 | <rniwa> | annevk: I have a completely unrelated question about "submit" event though |
| 06:48 | <rniwa> | annevk: does HTML or DOM spec have any text about how "submit" is stopped propagation at the first form element it encounters? |
| 06:48 | <rniwa> | I couldn't find any normative text |
| 06:48 | <annevk> | That looks like it might be an oversight, I'll investigate |
| 06:48 | <annevk> | rniwa: you're looking for https://github.com/whatwg/html/issues/3599 |
| 06:49 | <rniwa> | annevk: cool |
| 06:51 | <rniwa> | annevk: I did some investigation about that event.composedPath() seem to indicate Blink, Gecko, & WebKit all seem to simply stop the propagation instead of shrinking the event path |
| 06:51 | <rniwa> | annevk: it's crazy.. |
| 06:54 | <annevk> | rniwa: the amount of changes I had to make to the event dispatch algorithm over the years to account for weird stuff browsers implemented is rather staggering |
| 06:54 | <rniwa> | annevk: ya, truly mind boggling. |
| 07:00 | <rniwa> | annevk: it looks like we're also missing a special case of disabled form controls |
| 07:00 | <rniwa> | annevk: as far as I can tell, Gecko stop the propagation of all events on disabled form controls... |
| 07:01 | <annevk> | rniwa: I always assumed disabled form controls was some hit testing special case, but I never truly investigated... |
| 07:01 | <rniwa> | annevk: hit testing is working |
| 07:01 | <rniwa> | annevk: Gecko stops propagation |
| 07:02 | <annevk> | Okay, we really need more people to define all this legacy shit |
| 07:02 | <rniwa> | annevk: WebKit & Blink simply ignores the event; doesn't call event listeners but let the event pass through to ancestors LOL |
| 07:02 | <annevk> | o_O |
| 07:05 | <rniwa> | annevk: https://gist.github.com/rniwa/bf0f1411d6b811fcb605e796498740f3 |
| 07:05 | <rniwa> | annevk: Gecko outputs nothing |
| 07:05 | <rniwa> | annevk: WebKit & Blink says |
| 07:05 | <rniwa> | click on div |
| 07:05 | <rniwa> | test on button |
| 07:05 | <rniwa> | test on div |
| 07:07 | <annevk> | Well that's no fun, so much special behavior |
| 07:07 | <rniwa> | annevk: yeah, this is isane... |
| 07:07 | <rniwa> | annevk: I bet some websites rely on it though... |
| 07:08 | <annevk> | I like what Gecko does I guess, just return early if the target has some flag set |
| 07:09 | <rniwa> | annevk: i guess we'd have to check what it does if an event propagates to a disabled form controls |
| 07:09 | <annevk> | Although wait, that's not what it does, it goes through ancestors first |
| 07:09 | <annevk> | Yeah, it seems that if there's something on the path with a flag set, it returns early |
| 07:09 | <rniwa> | annevk: you mean like capturing? |
| 07:10 | <annevk> | rniwa: I mean that in your example you dispatch on <span> which is a child of a disabled element, so the path is span -> disabled element (ignoring other ancestors) |
| 07:10 | <rniwa> | annevk: i guess I should add event listeners to span |
| 07:11 | <annevk> | ooh, yes |
| 07:11 | <rniwa> | annevk: ok, so it dispatches to span! |
| 07:11 | <rniwa> | annevk: but then it stops |
| 07:12 | <annevk> | I guess that's similar to the <form> scenario? But it doesn't care about the event name here |
| 07:12 | <rniwa> | annevk: Blink & WebKit cares about event being a mouse event |
| 07:12 | <rniwa> | annevk: but Gecko doesn't |
| 07:14 | <rniwa> | annevk: okay, so capturing also only happens on span |
| 07:14 | <rniwa> | annevk: I think Gecko's behavior makes most sense here. it's truncating the composed path to 1. |
| 07:15 | <rniwa> | for some definition of "makes sense" |
| 07:15 | <annevk> | Ah okay, I was about to say that I don't understand how that would work, but if the path is very short I guess it does |
| 07:15 | <rniwa> | so maybe 1. restrict this behavior to mouse event & then truncate the event path at the first disabled form control |
| 07:15 | <rniwa> | might be good |
| 07:15 | <annevk> | That would argue for changing "get the parent" somehow |
| 07:15 | <rniwa> | ya |
| 07:15 | <annevk> | So form controls can have their own "get the parent" that sometimes returns null |
| 07:16 | <annevk> | No wait, that doesn't work |
| 07:16 | <annevk> | HTMLElement would need its own "get the parent" that special cases form controls |
| 07:16 | <rniwa> | oh no :( |
| 07:17 | <rniwa> | annevk: maybe modifying the dispatching algorithm in DOM is better. |
| 07:17 | <annevk> | Hmm, actually, probably Element, if we mix namespaces |
| 07:17 | <annevk> | Yeah |
| 07:17 | <rniwa> | annevk: scattering these quirks throughout different specs make it really hard to find out these edge cases |
| 07:23 | <rniwa> | annevk: my goodness. https://github.com/whatwg/html/issues/3599 goes through all elements during the capturing phase |
| 07:23 | <rniwa> | annevk: so these two quirks have completely distinct behaviors :( |
| 07:23 | <rniwa> | even within each browser! |
| 07:29 | <annevk> | Good times |
| 07:30 | <annevk> | rniwa: did you file an issue for the disabled control event path quirk? |
| 07:30 | <annevk> | rniwa: I agree that it makes some sense to not spread out quirks too much btw, but if they can be defined in terms of a generic mechanism that could be nice, but it seems that get the parent is not it |
| 07:31 | <annevk> | rniwa: we could also make the generic "get the parent" check for a [[Nope]] internal slot |
| 07:31 | <rniwa> | annevk: it's https://github.com/whatwg/html/issues/2368 |
| 07:32 | <rniwa> | annevk: I think I'm a bit worried about implementing Gecko's behavior given how permissive WebKit & Blink are. |
| 07:32 | <rniwa> | annevk: not firing event listeners sound crazy may not be the end of the world given we'd have to add some quirk somewhere |
| 07:33 | <rniwa> | annevk: i was hoping to get away by truncating/shrinking event path for both cases but it seems like we can't due to capturing phase |
| 07:33 | <annevk> | Okay, I don't care too much what we end up doing; I guess I'll wait and see what smaug____ says |
| 07:33 | <rniwa> | annevk: at that point, maybe we should go with whatever gets us compat with least effect |
| 08:22 | smaug____ | looks up |
| 08:22 | <smaug____> | something about disabled form elements |
| 08:23 | <smaug____> | blink was changing and planning to change the behavior recently |
| 08:27 | <smaug____> | oh, about the issue I filed |
| 12:52 | <annevk> | Hmm, I'm getting "The requested URL returned error: 400 Bad Request" from Bikeshed again |
| 20:51 | <TimothyGu> | annevk: is there a way for me to file bugs on bugzilla.mozilla.org without being given the default template? |
| 22:36 | <MikeSmith> | TimothyGu: you need to add &format=__default__ to the query params for the enter-bug URL |
| 22:36 | <MikeSmith> | https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&format=__default__ |
| 22:36 | <TimothyGu> | ahh |
| 22:36 | <TimothyGu> | how interesting |
| 22:36 | <MikeSmith> | heh yeah “interesting” is a good word for it |