| 00:04 | <bathos> | jyasskin I answered the question, tried to give attribution for your assistance, and quoted this chat: https://stackoverflow.com/questions/46642569/http2-push-and-native-es-modules-entry-module-push-is-ignored/46656731#46656731 |
| 00:04 | <bathos> | (let me know if you’d prefer I didn’t and I’ll edit accordingly) |
| 00:04 | <bathos> | I have a feeling this is gonna be helpful for others in the future in any case. |
| 01:47 | <wanderview> | Domenic: <script> tags is a subresource of a document/window... a worker script is a top level entity itself |
| 02:48 | <Domenic> | Still don't really understand why that matters. I guess we use different rules for picking the service worker in such cases but I don't understand why or what goes wrong when we don't. |
| 02:52 | <Mek> | I don't think anything goes wrong per-se. It just would be a bit weird where currently the service worker controlling a client is determined by the URL the client is loaded from being in scope of the SW, while for a cross-origin worker the URL would never be in scope. So either we change the logic to select a SW for all module workers (making them behave differently than non-module workers), or we only change it for cross-origin workers, which is also a |
| 02:52 | <Mek> | bit inconsistent. |
| 02:53 | <Mek> | To me it doesn't sound too strange to treat them similar to about:blank iframes etc, where we also just take the SW of the creating document as the controlling service worker. Treat cross-origin module workers almost like an anonymous "about:blank" worker that just happens to import a cross-origin module... |
| 02:53 | <wanderview> | there is no cross-origin non-subresource from a service worker perspective... it just matches scopes on that other origin |
| 02:53 | <wanderview> | right? |
| 02:55 | <wanderview> | what Domenic is asking for sounds like window.open(crossOriginURL) where it loads resources from another origin, but then would weirdly be forced the openers origin... |
| 02:57 | <wanderview> | Domenic: new Worker(url) is very similar to window.open(url)... they both open top level clients |
| 02:58 | <wanderview> | with the notable difference that we throw a security error for new Worker() if the url is cross origin from the current context |
| 03:00 | <Mek> | it's kind of new Worker("about:blank") followed by worker.write("import("cross-origin-url")), if that would be possible. I'm not saying it isn't different than what we do now, but it surely isn't impossible either. We'd juts have to decide how to treat it. |
| 03:01 | <Mek> | (and I'm not sure if the difference in treatment should be made at same-origin vs cross origin or at classic vs module worker) |
| 03:02 | <wanderview> | hmm |
| 03:04 | <Mek> | (and for what it's worth, I think having cross-origin (module) workers that actually are cross origin (access the other origins storage etc) would also be a worthwhile thing to explore, but yet again another complication (it would address at least some of the foreign-fetch/navigator.connect use cases, combined with nested workers) |
| 03:04 | <wanderview> | I guess I would be more comfortable just requiring the top level module URL to be same-origin to match classic script loading |
| 03:05 | <wanderview> | adding cross-origin worker support seems orthogonal to module loading to me |
| 03:18 | <wanderview> | or maybe thats what this PR is about |
| 04:32 | <annevk> | wanderview: agreed, will file an issue later with hopefully a detailed enough explanation |
| 05:47 | <JakeA> | jyasskin: bathos: also covered at https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/#requests-without-credentials-use-a-separate-connection |
| 08:38 | <tobie> | Hey folks, if you have thoughts &/|| comments to make about adding mixins to WebIDL, now's about the right time: https://github.com/heycam/webidl/pull/433 |
| 08:59 | <JakeA> | jyasskin: filed https://bugs.chromium.org/p/chromium/issues/detail?id=773219 |
| 11:16 | <ondras> | so, is calc() supposed to work in font: shorthand property? as in https://jsfiddle.net/29fsrxq3/ |
| 11:44 | <nox> | ondras: calc() is supposed to work everywhere until specified otherwise. |
| 11:45 | <ondras> | nox: thanks. will report a bug and a wpt test then. |
| 11:45 | <nox> | ondras: It appears big for me in both Safari and Chrome. |
| 11:45 | <ondras> | nox: right. but not in firefox. |
| 11:46 | <nox> | Yep. |
| 12:50 | <annevk> | hsivonen: what's a web-observable caller of "UTF-8 decode without BOM or fail"? |
| 12:51 | <annevk> | hsivonen: I thought I found one in HTML, but that appears to be an error when I tested |
| 13:16 | <annevk> | hsivonen: I found another decoder, the thing that navigates to fragments... |
| 13:16 | annevk | is not amused |
| 13:22 | <annevk> | hsivonen: also, it seems this endpoint doesn't allow a BOM to override it |
| 13:40 | <Domenic> | annevk: does not escaping % break the idempotency/parse-serialize-parse guarantees for URLs? Haven't checked but feels like it might. |
| 13:42 | <annevk> | Domenic: we only do something for %2e. But you cannot get that serialized I think. |
| 13:42 | <annevk> | Domenic: at least not in a place where parse will then take it away again |
| 14:04 | <annevk> | Domenic: hope the module worker issue is clear now |
| 14:05 | <annevk> | Domenic: also, are implementations first shipping import()? Before <script type=module>? |
| 14:05 | <annevk> | Domenic: or is <script type=module> happening before workers? |
| 15:27 | <hsivonen> | annevk: Web Socket as implented in Gecko, maybe? |
| 15:53 | <annevk> | hsivonen: that does indeed seem required as per https://tools.ietf.org/html/rfc6455#section-8.1 |
| 15:53 | <annevk> | hsivonen: I'll make a note of that in the source |
| 15:54 | <annevk> | hsivonen: ta |
| 17:15 | <annevk> | Hmm, NTLMv2 |
| 17:15 | <annevk> | I wonder if I want to explore that further; probably not |
| 17:16 | <gsnedders> | the answer is definitely not |
| 17:16 | <jyasskin> | JakeA: Thanks! |
| 18:34 | <TabAtkins> | ondras: Yeah, what nox said - calc() represents a <number> or <length> or whatever according to its contents, and should be usable *literally everywhere* that any of those types are accepted. |
| 18:43 | <ondras> | TabAtkins: thanks for confirmation. I already submitted a PR to web-platform-tests and there is an existing (~year) old report in mozilla's bugzilla. |
| 18:46 | <TabAtkins> | Cool. |
| 18:47 | <nox> | ondras: With Stylo landing soon, it will not get fixed in Firefox right now, |
| 18:47 | <nox> | ondras: but after Stylo lands, the Rust code that do the parsing is way easier to update to support this, so that's nice. |
| 18:48 | <ondras> | nox: I understand that Stylo is some brand new css engine for Firefox and people are focused at delivering it instead of fixing old bugs in the old css engine? |
| 18:49 | <nox> | ondras: Yes and no. |
| 18:49 | <nox> | ondras: Not supporting that in font doesn't break anything currently, |
| 18:49 | <nox> | ondras: supporting it *could* break things, |
| 18:50 | <nox> | ondras: and we can't afford to deploy Stylo and suddenly realise it breaks websites because it supports more stuff than the previous engine. |
| 18:52 | <ondras> | nox: I see, okay. (calc in font works in both Chrome and Safari, though.) |
| 18:52 | <nox> | ondras: Yeah, so for example, a website could have a font property with calc, for Firefox and Chrome, |
| 18:52 | <nox> | Err, Safari and Chrome* |
| 18:52 | <nox> | and a different font property for Firefox, without calc, |
| 18:53 | <ondras> | That is true. |
| 18:53 | <nox> | and while it's not much probable, supporting calc in Firefox could then break the site under Firefox (for example if the two fonts were different, because they didn't combine well with the rest of the stylesheet as interpreted by Firefox), |
| 18:53 | <nox> | and then we need to disable Stylo on that website, which sucks. |
| 19:03 | <TabAtkins> | Yeah, it's reasonable to want to separate out those concerns when doing a big launch. ^_^ It's not super-pressing, but it is important to fix eventually - calc() not working in random places is very frustrating for devs. |
| 19:15 | <ondras> | true that. |
| 19:16 | <ondras> | The point is that Custom Properties are almost useless without calc(), so I suppose that calc() is now getting a lot more attention. At least in my case :-) |
| 19:21 | <TabAtkins> | Ah, true! |
| 19:21 | <nox> | TabAtkins: It's frustrating to le me who participated into Stylo too! |
| 19:21 | <nox> | It takes more code to not support calc() in some places, than to support it everywhere. |
| 19:22 | <nox> | So we had issues about having to *unsupport* calc sometimes. |
| 19:22 | <TabAtkins> | Nice. |
| 19:27 | <annevk> | nox: seems we can undo thos now with 57 having branched? |
| 19:28 | <nox> | annevk: The story is "don't worry fam we won't forget about doing these changes afterwards". |
| 19:28 | <nox> | annevk: I myself have been kidnapped for a different adventure, so I'm not in the know anymore about that kind of mundane details. |
| 19:30 | <annevk> | Maybe SimonSapin knows? I’m curious now 😊 |
| 19:33 | <SimonSapin> | Right now pretty much any style system change needs to be done twice. It’ll all be much easier when we can remove the old style system |
| 19:33 | <SimonSapin> | but it’ll be a couple release cycles at least before we can |
| 19:34 | <SimonSapin> | we need to enable Stylo on Android, support XBL, etc |
| 19:35 | <annevk> | SimonSapin: ah ok, ta |
| 19:36 | <Domenic> | annevk: I'm still not sure on why shared workers would be nondeterministic. They are keyed by (creator origin, worker script URL) so they'd always use the service worker of the creator origin. |
| 19:38 | <Mek> | but which service worker of that origin? |
| 19:38 | <Domenic> | Oh. |
| 19:42 | <annevk> | Yup |
| 19:42 | annevk | curses scopes once more |
| 19:44 | <nox> | 360 noscope 4ever |
| 19:50 | <tobie> | Domenic: hey, so I found a reliable way to check that the WebIDL grammar stays LL(1) |
| 19:50 | <tobie> | Domenic: Which btw uncovered 3 violations in the existing grammar. :) |
| 19:50 | <Domenic> | Exciting :) |
| 19:51 | <tobie> | Well, I'm not sure exciting is the best way to characterize that… |
| 19:51 | <tobie> | But it's going to solve an otherwise painful problem. |
| 19:51 | <tobie> | Domenic: It relies on node.js + jsdom + syntax-cli + a custom JS script. |
| 19:52 | <tobie> | Domenic: and should be called by the deploy script (as it's going to be more robust if run on a build rather than on bs source) |
| 19:52 | <tobie> | Domenic: what do you think the best strategy is to incorporate it into the repo/travis file? |
| 19:53 | <tobie> | Domenic: this is basically what the script looks like: https://gist.github.com/tobie/ea7e12bb4cbbc5a28527684e7f14ef20 |
| 19:54 | <Domenic> | (Use new jsdom API plz ^_^) |
| 19:54 | <tobie> | Domenic: oh. sure. :D |
| 19:55 | <Domenic> | Basically I would borrow from https://github.com/whatwg/streams |
| 19:55 | <Domenic> | Setup travis as if it's a node project |
| 19:55 | <Domenic> | Check in a package.json and the .js file |
| 19:56 | <Domenic> | and run `node script.js` inside the deploy.sh |
| 19:56 | <Domenic> | be sure to update it to exit with return code 1 on failure |
| 19:56 | <tobie> | Cool. That's perfect. |
| 19:57 | <tobie> | That's what I had in mind, but wasn't too sure about all the details of handling multiple scripts. |
| 19:57 | <tobie> | All set now. Thanks. |
| 19:58 | <Domenic> | \o/ |
| 20:09 | <tobie> | Domenic: what did you do to jsdom!?!?!? it's about 2 orders of magnitude faster. o_O |
| 20:09 | <Sebmaster> | 🌈 |
| 20:09 | <Domenic> | lol, dunno, lots of work over time |
| 20:10 | <tobie> | Domenic: I was running 9.6.0, apparently |
| 20:11 | <Domenic> | tobie: ah, probably https://github.com/tmpvar/jsdom/blob/master/Changelog.md#971 |
| 20:12 | <tobie> | Domenic: that sounds about right (and pretty close to 2 orders of magnitude indeed) |
| 20:13 | <Domenic> | I wonder how many poor souls are stuck on 9.5.0-9.7.0 |
| 20:42 | <tobie> | well, one less today. :) |
| 21:05 | <smaug____> | <a href="javascript:window.open();" target="_blank"> Should that open one or two windows |
| 21:05 | <smaug____> | I assume two, since that would make sense |