| 01:18 | <domfarolino> | Domenic: service workers have their own environments right? (as in, a separate environment from the Window that created them) |
| 01:18 | <Domenic> | domfarolino: yes |
| 01:19 | <domfarolino> | Is it safe to assume then, the environment's creation URL would be the service worker's url? (https://w3c.github.io/ServiceWorker/#dfn-script-url) |
| 01:19 | <Domenic> | Depends on how they set up the environment... |
| 01:20 | <Domenic> | https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm seems to indicate so |
| 01:21 | <domfarolino> | Exactly what I was looking for. Thanks |
| 05:49 | <mathiasbynens> | “WhatWg is a controversial group. Their specs don't always follow official standards but Python does.” — https://bugs.python.org/issue34875#msg327006 |
| 06:03 | <MikeSmith> | mathiasbynens: haha |
| 06:04 | <MikeSmith> | recently somebody went in to some MDN articles and changed the text/javascript mentions to application/javascript |
| 06:04 | <MikeSmith> | based on that same rationale I guess |
| 06:04 | <MikeSmith> | I changed them back |
| 06:25 | <mathiasbynens> | MikeSmith: ♥ |
| 06:31 | <domfarolino> | annevk: Since in main fetch, we always generate request referrers (unless the `no-referrer`), you'd expect requests "passing through" a service worker to always have their referrer set to the service worker's URL no? |
| 06:35 | <domfarolino> | (SW's URL because webappsec rp sets "client" referrers to the environment's creation URL)...oh wait, actually I think requests passing through a SW will only have their referrers set to the SW's URL in the case where a SW forwards the request with a non-empty RequestInit, resetting referrer to "client" (https://fetch.spec.whatwg.org/#ref-for-concept-request-referrer%E2%91%A0%E2%91%A0), and using SW's URL |
| 06:37 | <domfarolino> | If that's right, I guess it feels a little strange that SW requests will have non-SW-URL referrers if the SW fetches w/o RequestInit...seems almost unrelated hmm |
| 07:55 | <annevk> | domfarolino: for passthrough it would already be initialized to a URL |
| 07:56 | <annevk> | domfarolino: and that is intentional so that adding a SW doesn’t impact observable bits (hence passthrough) |
| 11:28 | <domfarolino> | annevk: gotcha, we’d only reset it would for non-null RequestInits though though it seems. (i.e., if the SW “pass through” used fetch(..., {nonNull})) |
| 11:56 | <annevk> | domfarolino: yeah, because if the SW muddles with it, the SW gets the blame |
| 12:42 | <domfarolino> | Makes sense. Doesn’t seem as arbitrary now 👍 |
| 15:53 | <TimothyGu> | "wasm" is the word of the day on wiktionary today |
| 16:07 | <innovati> | nice! |
| 16:07 | <Domenic> | Even better when you read it https://en.wiktionary.org/wiki/wasm#English |
| 16:08 | <domfarolino> | Is a WebIDL dictionary "empty" if it contains no specified members, but was given unspecified/unexpected members? |
| 16:08 | <Domenic> | domfarolino: yes. The conversion from the JS object to Web IDL dictionary produced an empty dictionary. |
| 16:08 | <domfarolino> | perfect |
| 16:08 | <Domenic> | Extra members that are not specified in a dictionary's definition never get copied over into the dictionary structure |
| 16:09 | <domfarolino> | That's what I expected. cool |
| 16:16 | <domfarolino> | ...and of course I forgot to just check https://heycam.github.io/webidl/#es-dictionary |
| 18:37 | <Domenic> | Can document.domain share between http: and https:? |
| 18:41 | <Domenic> | Signs point to yes |
| 18:59 | <Mek> | Domenic: so the spec is wrong? (at least the spec seems to require two origins to have schemes that are equal to be considered same origin-domain) |
| 19:03 | <Domenic> | Mek: well I was reading the spec, so more likely I misread it :) |
| 19:04 | <Mek> | isn't the last example at https://html.spec.whatwg.org/multipage/origin.html#same-origin-domain your case? I.e. everything the same except http vs https, are not same origin-domain |
| 20:58 | <Domenic> | Mek: ah yes you are right |
| 21:20 | <MikeSmith> | Domenic: MDN annotations at https://arcane-cove-57093.herokuapp.com/multipage/ now have browser-support tables |
| 21:20 | <MikeSmith> | in the same style as the caniuse ones |
| 21:21 | <MikeSmith> | except at a higher level of granularity |
| 21:22 | <MikeSmith> | marked up with <details>/<summary> |