| 11:43 | <jgraham> | nox: Yes, the manifest is a good RIIR candidate and I started doing that (in a half-hearted way) at some point. But jdm's point is also true; we would either need to keep the Python stuff working or have a really good story for how to make it work for users (and projects) without rustc |
| 11:43 | <nox> | Does the manifest file format change often? |
| 11:43 | <nox> | It's not documented, though. |
| 11:43 | <jgraham> | If you are still seeing dozens of seconds to work out it has nothing to do then give us a profile please because dozens seems high; it should be under 5 |
| 11:43 | <jgraham> | (on reasonable but not exceptional hardware) |
| 11:44 | <jgraham> | nox: Not often but ocasionally. gsnedders is doing some (Python) perf work on it at the moment |
| 11:46 | <jgraham> | nox: (although based on the rest of your timeline I guess really if we'd just written it in lisp that would have solved all our problems) |
| 11:46 | <nox> | LOL |
| 11:46 | <nox> | jgraham: Yeah I had not realised it's way faster than it used to be now, I checked that a few days after my initial tweet and forgot to follow-up. |
| 11:51 | <jgraham> | nox: OK. I am kind of hoping we find time to replace the HTML parsing parts with html5ever at some point, so we might need to figure out the rust dependency thing anyway (but that can probably be a binary wheel, which I hope porjects can cope with). But yeah it's generally accepted that the performance of that tool is bad and also important |
| 11:52 | <nox> | jgraham: AFAIK TabAtkins doesn't think we can use html5ever given they want to mix HTML and Markdown parsing in one pass and whatnot. |
| 11:53 | <jgraham> | nox: Yeah, for Bikeshed it's probably harder than for the manifest itself |
| 11:53 | <nox> | Ah right, I'm mixing stuff. |
| 11:53 | <MikeSmith> | what’s a binary wheel? |
| 11:53 | <jgraham> | (but the distribution requirements on bikeshed are also pretty different since no one is using it in CI afaik) |
| 11:54 | <jgraham> | MikeSmith: A Python thing for distributing precompiled binaries |
| 11:54 | <MikeSmith> | ah OK |
| 12:31 | <annevk> | littledan: since we were talking about PR habits earlier, why do you force push a lot? |
| 12:32 | <littledan> | annevk: Oh, sorry about this, would you prefer a follow-on PR? |
| 12:32 | <littledan> | I guess it's because, in TC39, they don't end up squashing the patches, and it shows up poorly in the commit history if I don't squash them in advance |
| 12:32 | <littledan> | annevk: What would you prefer to make it easy to review? |
| 12:32 | <littledan> | not follow-on PR, but rather a stacked patch |
| 12:33 | <annevk> | littledan: in WHATWG land we squash (or rebase & merge in exceptional cases) and generally do "feedback/nit/typo" commits following the initial one |
| 12:33 | <annevk> | littledan: in the PR, so that the reviewer can review deltas |
| 12:33 | <littledan> | right, makes sense, I'll switch to that |
| 12:33 | <littledan> | thanks for explaining |
| 12:33 | <littledan> | and sorry for the noise |
| 12:34 | <annevk> | no worries |
| 12:34 | <gsnedders> | jgraham, nox: also manifest regen isn't a huge deal, IMO, because we rarely do a full rebuild of the manifest, and that's what's really slow |
| 12:34 | <annevk> | I really wonder why they prefer merge commits. Linear history is so nice... |
| 12:34 | <annevk> | (in TC39) |
| 12:35 | <littledan> | yeah, I don't really know who "they" is there; the editor group has its calls very late, and they don't seem to be publishing their notes or rationale anywhere. They've pushed back against people who raised these kinds of concerns. |
| 12:35 | <littledan> | we used to do that |
| 12:36 | <gsnedders> | jgraham, nox: and html5ever still has the problem of being UTF-8 only |
| 12:38 | <annevk> | gsnedders: sounds like a feature to me |
| 12:38 | <annevk> | gsnedders: though I guess not for parsing tests if that's the goal here 😃 |
| 12:38 | <gsnedders> | annevk: as long as web-platform-tests needs to test documents in other encodings, which it likely does as long as we support other encodings… |
| 12:39 | <gsnedders> | annevk: and probably not great for web compat in Servo either :) |
| 12:39 | <annevk> | littledan: okay, hopefully they'll elaborate in response to your question; if not I'll try to help out by prodding too |
| 12:40 | <nox> | gsnedders: Yeah it needs some rework to be able to cope with other encodings :( |
| 12:40 | <littledan> | yeah, thanks |
| 14:42 | annevk | notices "document family" in HTML |
| 15:16 | <annevk> | Domenic: so a Window object needs to hold a reference to a WindowProxy object |
| 15:16 | <Domenic> | This seems likely |
| 15:16 | <annevk> | Domenic: otherwise someWindowObject.self crashes (it currently does in the spec) |
| 15:17 | <annevk> | (can crash, when browsing context is null) |
| 15:18 | <Domenic> | I think at least some browsers will return null or undefined for that. |
| 15:19 | <annevk> | Domenic: right you are |
| 15:19 | <Domenic> | I guess there's a bigger question of what happens to someWindowObject's [[Window]] internal slot on BC discard |
| 15:19 | <Domenic> | In some browsers I think they null it out and start returning undefined/null all over the place |
| 15:19 | <Domenic> | But in others not so much |
| 15:19 | <annevk> | Domenic: nulling that seems fine since there should be no way to get to it? |
| 15:20 | <Domenic> | Well if you null [[Window]] then e.g. someWindowObject.Array is undefined |
| 15:20 | <annevk> | oh wait, no, that's not fine |
| 15:20 | <Domenic> | Which might be the case in Safari IIRC |
| 15:20 | <Domenic> | But this is treading close to an area where I recall Edge saying that it was web-interop-pain for them being over-aggressive on cutting references. |
| 15:20 | <annevk> | I guess that warrants further testing |
| 15:21 | <annevk> | I'm now -1 on adding a ref from Window to WindowProxy though; I'd like to see Firefox return null for self/frames/window |
| 15:21 | <Domenic> | Seems nice, although unclear how much it helps in general |
| 15:22 | <Domenic> | Because if you have someOtherWindowObject you're holding on to the WindowProxy anyway. |
| 15:23 | <annevk> | yeah, it's just one pointer less |
| 19:56 | <Domenic> | annevk: so what is stopping us from saying `fetch("https://example.com/";, { credentials: "omit" })`, i.e. no-credentials HTTPS fetches, can return non-opaque responses with no CORS needed? |
| 20:50 | <zcorpan> | Domenic: secrets in intranets with IP-based access? |
| 20:50 | <Domenic> | That are accessible over https://? |
| 20:51 | <zcorpan> | Not sure |
| 21:25 | <annevk> | Domenic: maybe nothing eventually, depends a bit on how things play out and whether that is indeed as secure as I hope it is |
| 21:26 | <Domenic> | That'd be crazy... all these years making developers deal with CORS and they could have just done that... |
| 21:26 | <annevk> | Domenic: well, it’s complicated |