| 01:42 | <GPH-Hickory> | Domenic++ |
| 01:44 | <GPHemsley> | FTR, I just touched a bunch of old wpt tickets about URL |
| 01:44 | <GPHemsley> | there aren't too many that are still open, which is cool |
| 01:44 | <GPHemsley> | https://github.com/web-platform-tests/wpt/labels/url |
| 01:46 | <Domenic> | Not bad |
| 01:48 | <Domenic> | https://github.com/web-platform-tests/wpt/issues/11218 is kind of depressing |
| 04:13 | <annevk> | Yeah, there is a real problem there. PSL maintainers saying it need not be relied upon and nobody else heeding their advice. |
| 07:52 | <mkwst> | annevk: Ryan's going to be in Zurich next week. I might be there as well. Maybe we can get coffee and argue about the PSL a bit. |
| 07:56 | <annevk> | mkwst: that'd bad timing, it's Mozilla week in SF |
| 07:56 | <mkwst> | Oh. :( |
| 07:56 | <mkwst> | Mozilla week somehow didn't make it onto my calendar. :) |
| 07:56 | <annevk> | mkwst: would have loved to though, it's a rather intriguing mismatch between the maintainers and how it's used |
| 07:57 | <mkwst> | I think he's in London this week for CA/B. |
| 07:58 | <mkwst> | Maybe we can set up a call or something. I don't really understand his position, though I agree with what I imagine it' |
| 07:58 | <mkwst> | its philosophical underpinnings might be. |
| 08:02 | <annevk> | mkwst: sounds good to me, available 9-5 daily and 7-8 if we cannot make it work otherwise |
| 08:40 | <mkwst> | annevk: I'll ping Ryan and see if he can carve out some time. |
| 08:54 | <annevk> | mkwst: should we wait for this meeting before proceeding with the URL PR? |
| 08:56 | <mkwst> | annevk: Meh. I think we need to define the terms somewhere. My impression is that Ryan's concerns are broader than this PR. |
| 08:56 | <annevk> | Fair enough, I'll give everyone until Wednesday just in case |
| 08:56 | <mkwst> | That seems totally reasonable. |
| 12:58 | <JakeA> | annevk: On background fetch's 'failed' event, I'm looking to communicate the reason for the failure (as long as security allows). Is there any prior art here? Would an enum 'reason' work? Creating an 'error' property would involve defining new error types, which seems bad. |
| 12:59 | <annevk> | JakeA: it seems like a bit of a layering violation if background fetch gets to expose that, but not fetch |
| 12:59 | <annevk> | JakeA: unless it's network error vs some HTTP layer errors only |
| 13:01 | <JakeA> | annevk: it wouldn't be anything new, but it'd distinguish between a quota error, a non-ok status code on one of the fetches, a network error... |
| 13:02 | <JakeA> | Another reason could be "underlying resource changed" if the etags change between partial responses |
| 13:03 | <annevk> | JakeA: okay, an enum seems fine I suppose, if that works for developers |
| 13:04 | <annevk> | JakeA: does background fetch enforce CORS? |
| 13:04 | <JakeA> | annevk: yes |
| 13:04 | <annevk> | great |
| 13:04 | <annevk> | one less vector to worry about |
| 13:04 | <JakeA> | :D |
| 13:11 | <wanderview> | JakeA: could you expose an exception type like NetworkError or QuotaExceededError on a property? |
| 13:11 | <wanderview> | or TypeError with a good message, etc |
| 13:13 | <JakeA> | wanderview: I'd probably have to create a load of new error types to allow code to test the difference. That feels worse than an enum, but I can't quite put my finger on why. |
| 13:13 | <wanderview> | JakeA: the one advantage of the error exception object types is that they allow you to provide a decent message... at least for TypeError |
| 13:14 | <wanderview> | JakeA: I guess it depends on if there is anything useful the site can do with the error other than just logging it |
| 13:15 | <annevk> | JakeA: the problem with that is that I think exception type messages are localized |
| 13:15 | <annevk> | wanderview: ^ |
| 13:15 | <JakeA> | Hmm, I'm going to collect all the possible failures we have so far, and see if the right answer becomes clearer |
| 13:15 | <annevk> | wanderview: so if you want to allow branching, what JakeA suggests seems better |
| 13:15 | <JakeA> | yeah, I'd have to create new error types if I was to use errors |
| 13:16 | <wanderview> | I only ask because in firefox we have an old enum-based system... and its a constant annoyance to me because I have to go plumb extra stuff to get good TypeError with messages so devs can actually tell what happened... enums are never fine-grained enough |
| 13:16 | <wanderview> | ok |
| 13:16 | <annevk> | JakeA: make sure to test that not-ok is only exposed after CORS succeeds |
| 13:17 | <annevk> | JakeA: and if you want granular non-ok, you'll either need two fields or a dictionary of sorts, since ~400 enum values seems like too much |
| 13:19 | <JakeA> | annevk: if the error is related to a particular fetch, we can point to the "record" that generated the failure. But yeah, CORS, SSL, MIX related failures will just be "network error" |