| 01:35 | <domfarolino> | Is there a section in the fetch spec where things like URL objects are converted into `Request`s before performing the fetch algorithm? |
| 01:36 | <domfarolino> | I ask because it mentions that the input for fetch is a Request, yet the fetch API takes in things like strings and URLs |
| 01:46 | <Mek> | domfarolino: see step 2 in the algorithm for the fetch method; it calls the Request constructor with whatever was passed to the fetch method |
| 01:46 | <Mek> | domfarolino: https://fetch.spec.whatwg.org/#fetch-method |
| 01:49 | <domfarolino> | Mek: wow how'd I miss that. Thank you! |
| 02:21 | <domfarolino> | Mek: perhaps you could answer this, what allows the Request constructor to be called with a URL object as its first param, and still work? Seems the constructor takes in strings and Request objects. |
| 02:23 | <Mek> | domfarolino: the magic of WebIDL, which stringifies whichever is passed in (and the URL interface has a stringifier defined) |
| 02:24 | <Mek> | (stringifies things passed to a method taking a DOMStirng/USVString) |
| 02:26 | <domfarolino> | Mek: Ok so an object with a stringifier defined will pass a "string" (DOMString/USVString) type check then? |
| 02:28 | <Mek> | domfarolino: well, anything will pass a "string" type check (i.e. there is no error throwing in the algorithm to convert a ecmascript value to a DOMString https://heycam.github.io/webidl/#es-DOMString) |
| 02:30 | <Mek> | actually, a Symbol would throw a TypeError in the ecmascript spec |
| 02:32 | <domfarolino> | Mek: Hmm so I just realized that URL.toString() is called when passing a URL into Request constructor. I guess I'm a little confused as to how in the Request constructor, we can get away with checking for the more general type "string" before checking for object of type Request. Because if an object of type Request can be seen as a string, wouldn't we ALWAYS pass the "if input is a string" condition? |
| 02:33 | <domfarolino> | I mean obviously we don't, but I'm just confused as to why. Because new Request().toString() will pass (just return an invalid URL is all) |
| 02:33 | <Mek> | domfarolino: see the algorithm for converting a union type from ES to IDL (https://heycam.github.io/webidl/#es-union) |
| 02:34 | <Mek> | the string conversion isn't attempted till step 14, Request will be handled in step 4 |
| 02:39 | <domfarolino> | Mek: Ohh so we don't delegate if we recognize a platform object first then |
| 02:39 | <domfarolino> | delegate to ecma ToString, that is |
| 02:39 | <Mek> | yeah |
| 02:39 | <domfarolino> | Ok this makes a lot more sense thanks! |
| 03:45 | <domfarolino> | Mek: could you help me understand step 4 substep 1 of the es-union algorithm you sent a bit ago. For example, `new Headers()` is a platform object (right?), however when passed into the `Request` constructor (which looks for a string) we fallback to calling `.toString` (step 14), and I'm not sure what condition in step 4 > substep 1 we're failing |
| 04:56 | <Domenic> | domfarolino: `new Headers()` does not implement `Request` |
| 05:06 | <domfarolino> | Domenic: hm does that mean 'new URL()' does then since we're caught at step 4 when passing in 'new URL()'? Or am I misunderstanding something |
| 05:09 | <Domenic> | No, new URL also fails step 4 substep 1 |
| 05:09 | <Domenic> | new URL ends up in step 14 |
| 05:23 | <domfarolino> | Domenic: Ok, so headers and URL are both platform objects so they attempt step 4 dubstep 1 which they fail and move on (eventually hitting 14) correct? |
| 05:23 | <domfarolino> | Substep ** autocorrect |
| 05:24 | <domfarolino> | but of course Request object passes fine |
| 05:26 | <Mek> | yeah, because Request is the only interface type included in "types" |
| 07:51 | <JakeA> | annevk: with background fetch I need to process the body of the response as it arrives. "process response" is ideal in terms of timing, but it requires an event loop that I may not have. Feels like the task queuing part should be optional. |
| 07:52 | <JakeA> | Has this come up before? |
| 07:53 | <Domenic> | JakeA: I think usually when there's no even loop you set the sync flag |
| 07:53 | <Domenic> | Hmm I guess that doesn't work for you |
| 07:54 | <Domenic> | Hmm per spec SRI disables streaming!? |
| 07:55 | <Domenic> | I guess that makes sense, but still.... |
| 07:55 | <JakeA> | Yeah, sync means it'll wait for the body before giving me the response |
| 07:55 | <Domenic> | https://fetch.spec.whatwg.org/#concept-fetch step 19 for the SRI thing |
| 07:56 | <Mek> | hah, that (streaming and packaging/sri/signature type things being incompatible) also came up over lunch... |
| 07:56 | <Domenic> | JakeA: I wonder if you should just have a simple event loop... |
| 07:57 | <Mek> | so change HTML to define a third type of event loop? |
| 07:59 | <JakeA> | I can't see how SRI can work without streaming. But that'll provide an interesting challenge for bg fetch too. |
| 08:01 | <annevk> | JakeA: how can you do callbacks without an event loop? |
| 08:23 | <JakeA> | annevk: In spec-speak, I can call out to another algorithm while I'm "in parallel". Given that the algorithm I'm calling is on the same thread, it doesn't seem like an event loop is needed for algorithmic callbacks. |
| 08:26 | <annevk> | JakeA: so you're happy to block yourself until you got a response, but no further? |
| 08:26 | <annevk> | JakeA: also, who says fetch is on the same thread? |
| 08:27 | <annevk> | JakeA: I wonder how background fetch integrates with "fetch groups" and the various timing APIs |
| 08:27 | <JakeA> | annevk: I'm happy to block until I've got a response, but it'd nice to hand back to fetch after that so it can process the trailer etc |
| 08:28 | <JakeA> | annevk: main fetch is on the same thread in as much as it can return a response |
| 08:28 | <annevk> | JakeA: you also need the body? |
| 08:28 | <annevk> | JakeA: in that case i'd just use the sync flag |
| 08:29 | <JakeA> | annevk: that waits for the response body |
| 08:30 | <JakeA> | annevk: Since background fetch can be multiple requests combined, I need to be able to handle the stream |
| 08:31 | <JakeA> | annevk: and a response that provides data before failing is still useful, as I can resume from there |
| 08:32 | <JakeA> | annevk: in terms of fetch groups, I'm still figuring that out. Use of clients is also interesting. I'm leaning on keepalive for now, but haven't looked too closely at it. |
| 08:45 | <annevk> | JakeA: so Fetch does have an open issue on making the callbacks more explicit |
| 08:45 | <annevk> | JakeA: maybe if that were fixed we could make things more flexible around event loops |
| 09:05 | <JakeA> | https://github.com/whatwg/fetch/issues/536 |
| 09:05 | <JakeA> | annevk: ta, I'll add my use-cases to that issue |
| 09:27 | <JakeA> | annevk: the more I think about it, the sync flag is perfect, except for the "wait for body" bit. Mind if I send a PR that adds a flag that means it *doesn't* wait for the body? |
| 09:30 | <annevk> | JakeA: it feels a bit like a hack at that point |
| 09:31 | <annevk> | JakeA: I'd be worried about the added complexity and ensuring everything remains working well |
| 09:32 | <annevk> | Domenic: thoughts on https://github.com/whatwg/html/issues/3043#issuecomment-329838865? |
| 09:32 | <annevk> | xfq: your welcome 😊 |
| 09:34 | <Domenic> | annevk: I haven't taken the time to look at the current spec enough to validate the design... Maybe later tonight I can. |
| 09:34 | <annevk> | Domenic: leave it then, I'll just go with something and see if it works |
| 09:35 | <annevk> | Domenic: and then we can bikeshed during review |
| 09:36 | <smaug____> | What is the security model for service workers |
| 09:36 | <smaug____> | when can a service worker run? |
| 09:36 | <smaug____> | security is wrong word |
| 09:37 | <annevk> | smaug____: it runs when a document associated with a browsing context or worker is created |
| 09:38 | <annevk> | smaug____: and then during the lifetime of that document/worker whenever stuff is fetched |
| 09:38 | <smaug____> | what about push? |
| 09:38 | <JakeA> | smaug____: that can run when there isn't an associated document open. But… |
| 09:39 | <JakeA> | smaug____: That requires user permission at registration time, and a notification must be shown as a result |
| 09:39 | <smaug____> | and there is no way to cancel such notification ? |
| 09:41 | <JakeA> | smaug____: no way to remove the notification without the user seeing it |
| 09:42 | <JakeA> | smaug____: There are some cases where you don't have to show a notification, eg there's a page to the origin open. The reason you have to show a notification is so the user is aware the site ran in the background, so there's no need to do that if it's already visibly running. |
| 09:43 | <smaug____> | sure. I'm just wondering in which all ways web sites may misuse users' machines |
| 09:43 | <smaug____> | running random JS code |
| 09:43 | <JakeA> | smaug____: There are use-case this gets in the way of. Eg, you show a notification on the phone "You have a new direct message", but the user views that message on another device, so you want to remove that notification from all devices. We don't have a good answer for that yet |
| 09:44 | <smaug____> | just read about that bitcoin mining using JS, but that, I guess, isn't SW related |
| 09:45 | <JakeA> | smaug____: With background fetch, the plan is to close the service worker during the fetch (unless it's otherwise needed), then run it again to handle completion events once the fetch is complete. During the fetch there'll be a download notification showing progress, so again it's very user-visible |
| 13:22 | <wanderview> | smaug____: JakeA: I don't believe the spec requires "notification must be shown"... firefox uses a different heuristic |
| 13:32 | <JakeA> | wanderview: it's somewhat in the spec https://w3c.github.io/push-api/#dom-pushsubscriptionoptions-uservisibleonly |
| 13:33 | <wanderview> | JakeA: we don't implement that: http://searchfox.org/mozilla-central/source/dom/webidl/PushManager.webidl#11 |
| 13:33 | <JakeA> | gothca |
| 13:33 | <JakeA> | um |
| 13:33 | <JakeA> | gotcha |
| 13:34 | JakeA | goes away to draw gothcat |
| 13:34 | <wanderview> | JakeA: gothca sounds like a pokemon to me |
| 13:34 | <JakeA> | haha |
| 13:35 | <wanderview> | JakeA: I wasn't directly involved in our push heuristic, but I think the idea is we believe the throttling is adequate and if a site is abusing it we slow their pushes to the point it doesn't matter |
| 13:35 | <wanderview> | but again, I'm not 100% sure |
| 13:38 | <JakeA> | I guess that enables the "hide notification" thing at the very least |
| 13:42 | <wanderview> | yea |
| 13:43 | <wanderview> | JakeA: AFAIK the `userVisibleOnly` thing is not feature detectable... does it have any observable change on script? |
| 13:44 | <JakeA> | wanderview: I don't think so |
| 13:45 | <wanderview> | ok, that makes me feel a bit better in not implementing it |
| 13:46 | <JakeA> | wanderview: I mean, if you don't set it to true, we always reject |
| 13:46 | <wanderview> | JakeA: what did you mean earlier about SRI not working without streaming? |
| 13:46 | <JakeA> | wanderview: don't you need the whole response before you know it matches the hash |
| 13:47 | <wanderview> | JakeA: right... ok... maybe I misread what you said |
| 13:47 | <wanderview> | JakeA: I guess it depends if we need to reject the outer fetch or if we can abort the body stream... but right now it requires not providing a Response with status=200 |
| 13:48 | <wanderview> | so we can't provide Response before the body is available |
| 13:49 | <JakeA> | wanderview: spec says reject the outer fetch |
| 13:49 | <wanderview> | JakeA: yea, I was more wondering if we could make that more forgiving now that streams exist... I think SRI was integrated before body streams |
| 13:50 | <wanderview> | but I don't think aborting the body is the same |
| 13:50 | <JakeA> | wanderview: ohh I see. Yeah, I guess it depends if header access for a non-matching response should be considered dangerous. But I guess it's fine |
| 13:50 | <wanderview> | or partial body data |
| 13:50 | <JakeA> | that's definitely risky |
| 13:50 | <wanderview> | seems unwise |
| 13:51 | <smaug____> | wanderview: Isn't userVisibleOnly feature detectable if one has a throwing getter for it in the object passed as dictionary |
| 13:51 | <wanderview> | smaug____: oh, I guess so |
| 13:51 | wanderview | doesn't know all the tricks... |
| 13:51 | <JakeA> | ohh yeah, I keep forgetting about that trick |
| 13:52 | wanderview | has to go do a code review on his house shortly. |
| 14:35 | <JakeA> | annevk: are you happy to address Domenic's nits in https://github.com/whatwg/html/pull/3038? In terms of comments on the stuff I wrote, there isn't anything I disagree with |
| 14:38 | <annevk> | JakeA: yeah, I likely won't get to it today though |
| 14:38 | <JakeA> | annevk: no rush, I just didn't want to get in the way |
| 17:43 | <annevk> | JakeA: ended up doing it |
| 18:08 | <JakeA> | annevk: hah cheers |
| 18:52 | <wanderview> | JakeA: if a user completely disables cookies in chrome, does that block service workers from working? |
| 18:52 | <wanderview> | similar to 3rd party cookies being disabled blocking service worker itnerception of 3rd party iframes |