| 12:10 | <JakeA> | annevk: Is there a standard way to escape , in header values? As in, if I want , to be considered part of a value, not separating multiple values |
| 12:32 | <annevk> | JakeA: use quotes |
| 12:32 | <annevk> | JakeA: quoted string, that is |
| 12:32 | <annevk> | JakeA: and the quoted string parser from Fetch |
| 12:35 | <JakeA> | ta! |
| 12:36 | <annevk> | JakeA: so we're kinda stuck with Background Sync btw and I guess a similar thing applies to Background Fetch |
| 12:37 | <JakeA> | annevk: Because of https://github.com/WICG/BackgroundSync/issues/152? |
| 12:37 | <annevk> | JakeA: and for Background Sync it also seems there's not much uptake so it's a bit unclear how much to invest |
| 12:38 | <annevk> | JakeA: well, the issues mentioned therein, not the note 😃 |
| 12:40 | <JakeA> | (I'll try to dig up some stats on bg sync) |
| 12:42 | <JakeA> | annevk: Is the issue that Firefox would like to show a permission prompt on first usage? I think background fetch has that covered, unless I'm missing something |
| 12:45 | <annevk> | JakeA: we're not sure there's sufficient value for a prompt or what exactly the prompt would say |
| 12:46 | <JakeA> | annevk: I get it with bg sync, but Firefox already allows downloads without prompts, so I don't see the issue with bg fetch |
| 12:48 | <annevk> | JakeA: I might have missed how bg fetch is different from bg sync |
| 12:49 | <annevk> | JakeA: I guess bg fetch is effectively keepalive + storage? |
| 12:49 | <annevk> | JakeA: it might be diff then |
| 12:49 | <annevk> | JakeA: might also benefit of a name that more clearly illustrates that |
| 12:51 | <JakeA> | annevk: bg fetch is more like `Content-Disposition: attachment`, in terms of resuming, visibility, user control. The difference is the developer has a little more control over what appears in the download notification (eg an icon), and the result isn't written to a place of the user's choosing, it goes into origin storage |
| 12:52 | <JakeA> | annevk: If naming is the blocker I'm sure we can do something about that, if we can get consensus around an alternative |
| 12:55 | <annevk> | JakeA: do browsers resume downloads after a connection is cut and the new connection is from a different wi-fi spot? |
| 12:55 | <annevk> | JakeA: if they do that kinda seems problematic to me |
| 12:56 | <annevk> | JakeA: cause you could just start a slow download and track the user as they travel around |
| 13:01 | <JakeA> | annevk: I haven't tested across wifi spots (https://resumable-downloads-test.glitch.me/ might be useful here). But there's a sticky notification throughout the download. |
| 13:01 | <JakeA> | annevk: We see ~2.5 billion/week uses of bg sync fwiw |
| 13:03 | <annevk> | JakeA: Firefox does show a prompt for the download there to me |
| 13:05 | <annevk> | JakeA: I guess that means a few popular sites have to use it, if there was some way to talk to them about a flow that involves a dialog that'd be good |
| 13:09 | <JakeA> | annevk: I get a prompt on Desktop, but I think it's configurable. The bg fetch spec supports starting downloads in a "paused" state, so this behaviour is fully compatible (aside from asking the user where to save the file) |
| 13:09 | <JakeA> | annevk: The reason it starts in a paused state, rather than using a permission prompt, is it means the download can be accepted after the page has closed |
| 13:11 | <annevk> | JakeA: yeah so with explicit UI there's much less of an issue for bg fetch, but maybe it shouldn't be "background" then 😃 |
| 13:11 | <annevk> | JakeA: anyway, thanks for the personal explanation, much appreciated |
| 13:12 | <JakeA> | annevk: that's fair. It's 'background' because it doesn't require any active client to complete. Maybe naming similar to keepalive is better? Renaming and aliasing until usage drops doesn't feel like a huge deal if we can all agree on a new name |
| 13:13 | <annevk> | JakeA: "Origin Downloads" is a thing that popped into my head, but not sure how great that is |
| 13:14 | <JakeA> | annevk: They can be cross-origin URLs though (as long as they're CORS) |
| 13:14 | <annevk> | JakeA: I'm also not sure if we need to rename APIs for this and to what extent Fx wants to implement at this point (I'd need to ask around a bit more) |
| 13:14 | <annevk> | JakeA: I meant Origin for the destination, but I see how that's confusing |
| 13:14 | <annevk> | JakeA: maybe Storage Downloads then |
| 13:15 | <JakeA> | annevk: I've avoided 'downloads' because it can also be used to eg upload a gallery of images. Naming is hard. |
| 13:17 | <annevk> | JakeA: and in that case there's no storage happening either? |
| 13:19 | <JakeA> | annevk: The storage part of bg fetch is only for the duration of the fetch, once the fetch is complete it goes "here's your responses" and if you don't do anything with them, they're gone. |
| 13:19 | <annevk> | JakeA: but I assume you tell it ahead of time what to do? |
| 13:20 | <JakeA> | annevk: you give it the requests ahead of time, but you don't say what happens with the responses until the "complete" event |
| 13:21 | <annevk> | JakeA: oh, so code is run, hmm |
| 13:22 | <JakeA> | annevk: yeah, that's true. If that's a sticking point we could look at stuff like deferring that event until the user revisits the site. That might be doable. |
| 13:22 | <annevk> | I'm not sure if it is |
| 13:23 | <annevk> | JakeA: why not only have this and also have bg sync? |
| 13:23 | <JakeA> | annevk: bg sync is invisible, but won't stay alive long enough for larger fetches |
| 13:24 | <JakeA> | annevk: I guess you could still use bg fetch for posting a chat message, but maybe a notification is overkill? |
| 13:26 | <annevk> | JakeA: the problem is the "evil" sites |
| 13:27 | <annevk> | JakeA: if we always had visual UI for activity beyond the lifetime of a tab I think the whole thing is much more acceptable |
| 13:27 | <annevk> | JakeA: if the user closes mail.example and sees that bar (or something appear) that'd likely be fine with them and if it appears after visiting game.example they might close it down |
| 13:28 | <annevk> | JakeA: this also makes it fully transparent when sites are using your battery or are potentially tracking you, which bg sync fails at |
| 13:29 | <annevk> | JakeA: I rather like those aspects |
| 13:30 | <JakeA> | annevk: it seems reasonable for UAs to show a notification or something while there's a pending bg sync from an origin. Also seems reasonable for that notification to be cancellable. But yeah, it starts to merge with bg fetch at that point. Might not be a bad thing. |
| 13:32 | <annevk> | Yeah, not sure we need both though |
| 13:34 | <JakeA> | annevk: if I had to pick one for Moz to implement, it'd be bg fetch, especially if a notification would be used for both. |
| 13:37 | <annevk> | Yeah, in terms of how that works it seems much more aligned with how Mozilla "thinks" about these kind of things |
| 18:05 | <Domenic> | annevk: ping on https://github.com/whatwg/html/pull/4759 review, should be pretty straightforward |
| 18:20 | <annevk> | Domenic: I cannot r+ from here, but looks good |
| 18:21 | <annevk> | Domenic: does seem like we need an abstraction for hyperlink elements as we also forgot SVG a for :link and such right? |
| 18:22 | <Domenic> | Yeah, I mean, it's kind of unclear how much of that is our responsibility, but that's probably the right move |
| 19:34 | <annevk> | I doubt anyone else will take it on, but that would be nice |