2020-04-01 [19:46:47.0000] Domenic: do you know if Location in Blink was ever changed to inherit from URLUtils and then changed back? [19:47:44.0000] I mean similar to what happened in Gecko, with https://bugzilla.mozilla.org/show_bug.cgi?id=887364 changing Location and then https://bugzilla.mozilla.org/show_bug.cgi?id=1213815 changing it back [19:59:32.0000] MikeSmith: can't see anything in the history at least? [20:08:14.0000] gsnedders: same here [20:08:46.0000] I searched through change history for the source, also through bug tracker [20:10:44.0000] context is that I just want to update https://github.com/mdn/browser-compat-data/blob/master/api/Location.json#L342 to indicate there’s not password or username members for the interface in any current browsers [20:11:47.0000] but I know from experience with getting review on similar changes, reviewers aren’t gonna let me just change version_added: true to version_added: false there for Chrome [20:59:26.0000] FYI https://github.com/mdn/browser-compat-data/pull/5925 [00:18:10.0000] I've moved spec-factory to the WHATWG organization [00:18:32.0000] I'll add a README momentarily [01:41:50.0000] Oh wow, XMLHttpRequest uses "obtain unicode" [02:55:01.0000] /me wonders if MikeSmith could review https://github.com/whatwg/fullscreen/pull/167 [02:55:19.0000] /me looks [02:55:56.0000] annevk: yeah will do right now [03:35:35.0000] annevk: wow, just now took a trip down the location.ancestorOrigins rabbit hole [03:35:44.0000] via https://github.com/whatwg/html/issues/1918 and https://bugzilla.mozilla.org/show_bug.cgi?id=1085214 [03:42:32.0000] MikeSmith: I'm sad that didn't go anywhere, I put a lot of effort in that [03:42:40.0000] yeah I can see [03:42:54.0000] stalled about a year ago I guess [03:42:54.0000] At some point I should push for it again I suppose [03:43:27.0000] would be nice to get it resolved [03:44:30.0000] so about the history, I have gone back in time as a far as https://bugs.webkit.org/show_bug.cgi?id=83493, where it was first implemented in WebKit, but what’s the prehistory before that? [03:45:02.0000] MikeSmith: I think that's probably it [03:45:09.0000] OK good [03:45:24.0000] well then I was confused by a comment from Ian [03:45:34.0000] https://bugs.webkit.org/show_bug.cgi?id=83493#c19 [03:45:43.0000] “I'll make sure to either match implementations or not conflict on names when I spec this” [03:46:19.0000] I thought that implied some implementation prior to the WebKit one [03:47:10.0000] MikeSmith: implementation came first and Ian said that he might change semantics when speccing [03:47:16.0000] MikeSmith: and if he did, he'd change the name [03:47:30.0000] I see [03:47:46.0000] I guess the plural “implementations” there is what confused me [06:45:23.0000] I've updated branch protection rules for most repos and also enabled auto-deletion of branches belonging to merged PRs. If any of this sounds concerning or you run into something, now you know who to talk to. [08:33:57.0000] annevk: wrt the jsdom suggestion, I mean I think it'd be great for jsdom, but if the person proposing the change successfully implemented in an actual browser (and no existing WPTs broke) then I think it should be fine too [13:14:27.0000] TimothyGu: it’s somewhat seldom that those predate spec changes unfortunately [13:15:54.0000] Maybe not that unfortunate, but it means that some changes are tricky [14:59:15.0000] annevk: ping 2020-04-02 [17:35:01.0000] I see https://bugs.chromium.org/p/chromium/issues/detail?id=571722#c21 “User-Agent isn't currently allowed to be set. Mark the TestExceptations against it.” but I nothing in the current Fetch spec that disallows setting User-Agent in fetch requests [17:35:34.0000] not at https://fetch.spec.whatwg.org/#forbidden-header-name nor anywhere in the spec [18:10:03.0000] MikeSmith, related? https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/ [18:11:20.0000] how about Sec-UA-* ? [18:12:43.0000] erm.... Sec-CH-UA-* [18:13:53.0000] https://wicg.github.io/ua-client-hints/#fetch-integration [20:05:18.0000] shu: kinda here now [23:12:59.0000] TabAtkins: I see I can push to Bikeshed master; if I did that, would api.csswg.org update automatically? [23:19:41.0000] annevk: yes [23:23:21.0000] TabAtkins: cool, rest assured, I'll make sure CI is passing [23:23:56.0000] And I need to wait for Domenic to wake up to align on some other bits [23:24:53.0000] Cross-repo-dependency count is at 16 [09:52:59.0000] what does it mean for the _active script_ in https://html.spec.whatwg.org/#hostenqueuepromisejob to be null? [09:53:35.0000] is it for the case for a web platform feature enqueuing a promise job without running author script? [09:55:13.0000] shu: sounds likely [09:55:37.0000] shu: "active script can be null if the user clicks on the following button:" [09:55:59.0000] ooh, doh, there's an example, thanks [09:56:34.0000] Domenic: am i reading that correctly then it's those other hooks that set up the execution context? i'm not really finding where that's done [09:57:21.0000] shu: if I understand what you mean, you are looking for https://html.spec.whatwg.org/#prepare-to-run-script ? [09:58:53.0000] Domenic: not quite, my confusion is: step 5 creates a new execution context to be pushed inside the microtask itself, to propagate active script forward in time. but if there is no active script, there must still be a JS execution context to run the microtask. where does that execution context come from? is it guaranteed to exist already on the stack due to the other import host hooks? [09:59:48.0000] prepare-to-run-script says it's propagated via the other settings objects [09:59:58.0000] shu: Ah. The execution context will then be the one pushed via step 6.2. [09:59:58.0000] just trying to put the pieces together with the settings objects stacks [10:00:23.0000] ah, beautiful, ty [10:00:43.0000] That doesn't seem particularly intentional FWIW... [10:01:05.0000] But I guess it works [10:01:43.0000] Domenic: probably won't have time to finish the .pr-preview.json cleanups today [10:01:55.0000] Domenic: if you could set up the remaining bits I can do it tomorrow though [10:02:42.0000] annevk: for sure, will do; meant to do it before you signed off but this morning got hit by some surprise issues [10:03:23.0000] Domenic: all good [14:58:27.0000] Someone should fix https://developer.mozilla.org/en-US/docs/Glossary/URI [15:07:24.0000] https://www.ryanpickren.com/webcam-hacking is quite something [15:07:32.0000] Lots of origin/URL-related madness [15:08:53.0000] It's mostly finding terrible corners of specs, and then finding corners of those corners that weren't implemented correctly, in order to create exploits. 2020-04-03 [18:57:28.0000] glad to see that `document.open`/`write` makes a cameo ;) [19:10:59.0000] Domenic: in the MDN annos, I’m noticing a weird bug that despite having spent time stepping through the code, I still have no insight about why it might be happening [19:11:05.0000] the bug is that in single-page output, some MDN annos that are present in the multipage output are not present in the single-page output [19:11:42.0000] compare https://html.spec.whatwg.org/multipage/webappapis.html#the-promiserejectionevent-interface to https://html.spec.whatwg.org/#the-promiserejectionevent-interface [19:12:21.0000] that bug is causing literally hundreds of annos to not appear in the single-page output [19:13:53.0000] can you think of any difference in how we do single-page output that might be the culprit? [19:15:22.0000] MikeSmith: I don't have enough of wattsi loaded into my head to really answer that, but I do remember vaguely running in to this sort of mystifying difference between the two... I can try to take a better look tomorrow. File a quick issue so that I have it in my inbox? [19:15:43.0000] Domenic: OK will do [19:15:59.0000] thanks [19:28:01.0000] https://github.com/whatwg/wattsi/issues/111 [19:28:33.0000] maybe one of the many other Free Pascal coders who hang out here will step in to fix it 😛 [20:09:59.0000] did import.meta.currentScript ever get past the multiple script issue [07:52:38.0000] devsnek: nope [07:53:50.0000] i guess you'd end up needing some sort of crazy event model for when a script uses the instance [09:00:12.0000] Domenic: wanna do the .pr-preview.json stuff today? [09:00:22.0000] annevk: yep, working on it now :) [09:00:47.0000] \o/ [09:10:56.0000] Domenic: if you know who from Google to copy on https://github.com/whatwg/html/pull/5425 that'd be good [09:11:25.0000] annevk: Eric Law is probably the right person for Chromium but maybe we can get someone from Google... [09:12:45.0000] k [10:04:43.0000] TimothyGu: ping? [10:04:56.0000] ecobos: pong [10:05:38.0000] TimothyGu: hey, I was unsure whether https://bugzilla.mozilla.org/show_bug.cgi?id=1627285#c1 was incomplete or something (or maybe I just didn't parse it properly, not a native english speaker) [10:05:48.0000] oops, clicked send too early [10:05:59.0000] TimothyGu: did you plan to send a fix? Or should I go ahead and send the patch? It's pretty trivial to fix [10:06:04.0000] I meant to say that I could help fix it in Firefox [10:06:11.0000] Yeah I actually just wrote one [10:06:17.0000] TimothyGu: ah, if you want to I won't stop you :-) [10:06:37.0000] TimothyGu: glad I asked before writing it then ;) [10:06:39.0000] TimothyGu: thanks! [10:18:41.0000] Domenic: hmm GitHub is having many issues, so not gonna risk it now [10:18:48.0000] Aww OK [10:19:05.0000] Domenic: how does Bikeshed get all the relevant data from a PR number alone? [10:19:21.0000] annevk: it turns out that's all the data you really need [10:19:27.0000] Previously we were linking to the PR's head commit [10:19:34.0000] Which required commit SHA + repo owner [10:19:50.0000] But if you take a step back, why would that be a good idea? Linking to the PR itself is much nicer. [10:20:11.0000] It just needed some extra work to add a dedicated PR preview template instead of reusing the commit snapshot one. [10:21:00.0000] Ah okay, I guess it is nicer to link to the PR as it might also change over time, just like the PR [10:21:41.0000] Domenic: you'd kinda think that pr-preview already has the PR number btw as that's used for the filename [10:22:07.0000] Yeah it does, you just need to pass it to Bikeshed. [10:23:16.0000] Oh right, these are Bikeshed instructions. Next level would be { src: "....bs", type: "whatwg" } I guess 2020-04-04 [09:54:58.0000] anyone on right now? i have an issue with iframes :( [09:56:24.0000] i'll just go ahead and rant, then [09:56:47.0000] i have a site with a page that is specifically intended for other sites to embed via iframe [09:57:30.0000] for the user's convenience, if the user is already logged in to my site they should be able to access their logged-in account via the iframe [09:57:53.0000] and this used to work but then browsers starting adding inconsistent/buggy support for 3rd party cookies [09:58:27.0000] so i thought, ok I don't really need a cookie, I could just store a session id with localStorage since all the access is with javascript I can just add that token in a header [09:58:58.0000] but the trouble is that localStorage seems to be blocked by browsers via the same setting that blocks 3rd party cookies [10:00:09.0000] so site A loads an iframe with a page from site B, and the iframe tries to store foo=bar in localStorage, the browser interprets that as a request to store under site A's local storage and that's blocked if the user has "block 3rd party cookies" [10:00:16.0000] Yes, I think browsers are generally moving away from letting iframes track people around the internet in that way [10:00:23.0000] localStorage, cookies, whatever [10:00:25.0000] yes but it's not about tracking users across sites [10:00:42.0000] it's about communicating with users of my own site [10:00:43.0000] Knowing who the user is (i.e., accessing their logged in account) is tracking them [10:00:52.0000] in fact I don't want my localStorage associated to site A at all [10:01:05.0000] I'd like a localStorage in an iframe that is associated only to the site the iframe came from [10:01:43.0000] The difficulty there is that the browser would need some guarantee that the embedding site never tells the iframe "I exist" [10:02:39.0000] there could have been some iframe option to say, allow iframe-origin localStorage and block postMessage at the same time [10:02:57.0000] It'd have to be stricter than that [10:03:28.0000] No headers, no query params... actually, I can't think of anything that would work, because you can just use the URL path [10:03:53.0000] E.g. [10:03:58.0000] if the parent site wants to leak the user's identity i don't think you can stop it [10:04:02.0000] Right [10:04:06.0000] Which is why browsers are doing this [10:04:13.0000] So that once it's leaked, there's no way to store it [10:04:29.0000] Domenic: using allow="" as additional guard for SAB postMessage() doesn't seem unreasonable to me, how serious is this proposal? Mainly wondering if you thought through all the changes required already. [10:05:07.0000] annevk: it is new and just something that came up. We have not thought it through very much but wanted to start a discussion earlier rather than later. [10:05:07.0000] Domenic: in particular, I'm wondering if it should influence the public crossOriginIsolated getter and perhaps availability of the SAB constructor [10:05:17.0000] Domenic: kk [10:05:52.0000] annevk: it's a bit weirder for Chrome since this is all about a future move to lock up SAB, instead of about how to expose SAB. [10:06:33.0000] Influencing SAB constructor makes sense, unsure about the crossOriginIsolated getter [10:06:50.0000] If the meaning of crossOriginIsolated is "powerful features available" then that makes sense [10:07:01.0000] If the meaning is "COOP+COEP enabled" then maybe not [10:07:11.0000] Probably "powerful features available" is more useful [10:13:56.0000] iframe with postMessage was a great solution to let a site integrate a feature from a second site, while protecting the javascript in both directions [10:14:37.0000] so trying to do this in a way that respects user privacy, meaning it still works with all privacy settings enabled (but still allowing javascript) [10:15:52.0000] can it still be done? if the user has an account at parent site and also on the iframe site, it seems like now the iframe will also need to have a login form inside [10:16:48.0000] definitely don't want the user to login through the parent site and reveal their credentials to some other site [10:16:58.0000] and if we develop a plugin now we have to do it separately for every browsre [10:17:00.0000] xalqor: I am not an expert, but my understanding is that yes, logging in a second time is the current direction browsers are heading. [10:17:57.0000] but it's not just a second time, it's also every time they visit the parent site -- because the iframe can't store the cookie or anything in localStorage to remember that session across reloads [10:19:00.0000] Hmm, I thought the plan was just a second time, i.e. you'd get a different storage partition for when you're top level vs. when you're embedded in site A vs. when you're embedded in site B. [10:19:20.0000] if 3rd party cookies & storage is blocked then it doesn't work [10:19:32.0000] and i don't want to tell my users to disable that setting -- because it affects them on all sites [10:19:52.0000] Well I guess that setting is basically saying "don't allow embedded iframes to store any state" so it makes sense that it would prevent use cases like that [10:21:42.0000] (embedded _third-party_ iframes, that is) [10:22:07.0000] yeah [10:24:03.0000] thanks for the chat, i will need to rethink how i'm doing this thing [10:25:39.0000] Happy to help! [10:42:06.0000] Domenic: I’d like to keep the number of (public) booleans down I think. It’s confusing enough as-is 2020-04-05 [12:35:12.0000] Would it make sense to update the definition of a date string, to allow a single digit for specifying the month/date? It'd be nice to remove the need for zero padding, when code setting the attribute doesn't have it by default. [12:35:39.0000] The particular use case I have is when programatically setting the max attribute on a date input. [13:07:55.0000] oliverdunk: it'd add parser complexity and I'm not sure it'd help with readability either [13:22:35.0000] annevk: It seemed like the "parse a date component" section would only need a small tweak, and I hoped the difference in readability was negligible. I trust your gut though, thanks for replying. [16:34:14.0000] botie, inform rniwa does the Safari version data at https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/slot#Browser_compatibility make any sense at all? It claims the "slot" attribute was “Implemented with the vendor prefix: -webkit-” in Safari 10 — though without the prefix in iOS Safari. It as never actually implemented as an attribute named "-webkit-slot" anywhere, right? [16:34:14.0000] will do 2020-04-06 [00:25:44.0000] Domenic: the one small downside from this .pr-preview.json change is that all PRs will need rebasing I think [00:34:08.0000] Domenic: all is ready to go now, I suggest we do it when you and I have some time in case of fallout [04:52:10.0000] FYI, one trick to make GH rebase the merge commit against latest master for webhooks etc is to close/reopen any PR (so long there is no conflict). [07:11:46.0000] annevk: now is a good time for me [07:12:32.0000] Domenic: okay, so first Tab's PR, then whatwg.org, then the .pr-preview.json ones? [07:12:47.0000] Yeah, I think that's it! [07:17:51.0000] Domenic: can you do https://github.com/whatwg/streams/pull/1034? [07:18:30.0000] Will do [07:20:47.0000] Given https://travis-ci.org/github/whatwg/compat/builds/671502607 I guess it takes some time for api.csswg to update [07:22:29.0000] I also see that we're getting a shellcheck warning for not using H1 anymore [07:23:05.0000] Uh oh [07:23:17.0000] I'll clean that up now [07:23:36.0000] I'm worried about the bikeshed update. Is it still stuck on Python 2? [07:24:08.0000] That's a good question sigh [07:24:40.0000] /me wonders if TabAtkins is awake [07:27:20.0000] Yeah what up [07:28:12.0000] The server is on py3 now and receiving webhook notifications, so should be picking up updates now [07:28:26.0000] Thanks! It does indeed seem to be working now [07:28:39.0000] That is, whatwg/compat just went successfully [07:29:11.0000] whatwg/dom looks good too [07:29:50.0000] Phew! [07:30:10.0000] Auto-deletion of branches is really nice [10:58:32.0000] Why can't we add multiple IDs to elements? [13:39:47.0000] microtasks queues are 1:1 with event loops, right? [13:55:44.0000] shu: correct in specs. I hear Chromium is not quite like that. [13:57:16.0000] Domenic: i see [13:57:32.0000] Domenic: the intended state we want is agent:event loop:microtask queue 1:1:1? [13:57:45.0000] shu: yes. That is also the state in specs currently. [13:57:50.0000] cool, thanks [13:59:06.0000] Domenic: to make sure i understand, that'd mean since same-origin iframes are never their own agents, they never have their own microtask queues [13:59:48.0000] shu: right. [14:00:23.0000] Otherwise order would be unpredictable between same-origin iframes, which is undesirable, since they can sync script each other already. [14:00:38.0000] yeah [14:00:53.0000] We should be able to assign multiple IDs to an element. I don't know why we cannot, aside from "it's been that way". [14:01:13.0000] there's (as always) weirdness in detached iframes, but... that'll get sorted out whenever detached iframes in general get sorted out, i guess [14:01:30.0000] I understand that browsers will try to act as a coverall for ID attributes containing whitespace, and will consider it as a part of the ID itself. [14:01:51.0000] But really, this happens because of the spec saying that there is only ever one value. Why can there only ever be one value? [14:02:38.0000] an ID can be used for many things, but one of the most common is for CSS selection. It is also used for other things, like various form controls to be hit with a