| 00:52 | <sideshowbarker> | I worked on the mdn-spec-links build over the weekend but still have a handful of related changes I need to make before I can get the spec json files properly updated. Basically, the build is CI-automated such that every time a change is made the BCD or MDN sources, if that change affects any of the mdn-spec-links data, the CI generates a new PR that I then review and merge. However, the CI build first does a check to verify that all the URLs and fragment IDs in the spec links in BCD still exist — and if it finds any that don’t exist, the build fails. And to get the build working again, I need to fix the broken URLs/fragments, with PRs upstream in BCD. And things like big “Navigation and session history rewrite” (navigables) change to the HTML spec can really generate a lot of links that need to be fixed — in that case, for example, it caused the filename part of dozens of BCD URLs to change to But anyway, I only have a few broken URLs/fragments left to fix, and I should be able to get them done today, and everything will then hopefully be back to normal again (as far as my CI generating mergeable PRs that are all green). |
| 00:56 | <sideshowbarker> | smaug: https://bugzilla.mozilla.org/show_bug.cgi?id=1828286 looks like an interesting issue with FF adding fetches from iframes to history unexpectedly — and in turn causing the back button to not take the user back to where they’d expect (or really, not seeming to the user to take them back to anywhere at all) https://stackoverflow.com/questions/76026846/how-to-work-around-firefox-adding-fetches-from-iframes-to-user-s-browser-history is a related Stack Overflow Q&A |
| 04:04 | <Domenic> | I think the fetch is a red herring and it's setting the child src that creates a new history entry (which is per spec) |
| 04:05 | <Domenic> | In some browsers the back button can skip history entries though: https://github.com/whatwg/html/issues/7832 |
| 04:06 | <Domenic> | Although I dunno I guess Kaiido investigated and seems to think the fetch is to blame, so maybe I'm wrong |
| 04:30 | <Kaiido> | No, I didn't do any investigation specs wise. I barely just tried a few possible workarounds as asked on the SO question and provided a repro to the FF issue. At very least I find it surprising that a fetch call triggers this seemingly unrelated behavior, but that's about it. |
| 04:32 | <Domenic> | Yeah I meant you repro'd the issue in Firefox, and probably checked that it was actually due to fetch instead of due to the setting of src |
| 04:36 | <Kaiido> | It's when both are true that it reproes. So you may very well be right that calling `fetch` is part of the heuristics here. |
| 04:59 | <sideshowbarker> | In some browsers the back button can skip history entries though: https://github.com/whatwg/html/issues/7832 |
| 05:06 | <Domenic> | It's unfortunately a lot more complicated than "no user interaction", at least in Chromium. And it's still changing. |
| 05:29 | <sideshowbarker> | ah OK |
| 05:30 | <sideshowbarker> | Domenic: by the way, you planning to attend any part of the TAG face to face? And do you know if there’s an agenda available? Or else, if you know of anything particularly interesting that they’re planning to handle at the face to face? |
| 05:31 | <Domenic> |
|
| 05:32 | <sideshowbarker> | ah OK. Well Google is hosting it in the Shibuya office, right? |
| 05:35 | <Domenic> | That is news to me! |
| 05:35 | <sideshowbarker> | oh, then I could be wrong. Maybe it’s at Apple’s office, if they have one here. Looking for the info now… |
| 05:36 | <sideshowbarker> | https://github.com/w3ctag/meetings/tree/gh-pages/2023/04-tokyo |
| 05:36 | <sideshowbarker> | Shibuya Stream, hosted by Google Japan, it says |
| 05:38 | <sideshowbarker> | I guess the TAG needs to maybe do a better job of getting meeting info out more widely |
| 12:16 | <Pike> | The wiki seems to be down? |
| 22:36 | <TabAtkins> | Domenic: ping on https://github.com/whatwg/meta/issues/271#issuecomment-1499733981, I'm delaying a Bikeshed release for this |
| 22:48 | <Domenic> | Domenic: ping on https://github.com/whatwg/meta/issues/271#issuecomment-1499733981, I'm delaying a Bikeshed release for this |
| 22:51 | <TabAtkins> | Okay, so the easiest solution is (2) for now, then - just stop doing the special WHATWG stuff and let Bikeshed do its thing. You can change strategy later if one of the other options appeals more. |
| 22:52 | <TabAtkins> | I can't indefinitely delay the Bikeshed release, tho, and it will break your dfn panels right now. |
| 22:52 | <Domenic> | Ok, well, I don't know what to say. I've spent as much time on that issue as I can, probably for this quarter. |
| 22:57 | <TabAtkins> | I mean, okay? I'm telling you what will happen if you don't do anything, and it's so far had two weeks to work with. We can work with a little more time, but I'm going to have to pull the trigger. I've told you the easiest fix, but if you can't do it (and nobody else can) then, uh, WHATWG specs will have broken dfn panels at some point soon, until one of y'all can fix it. I can futz with your build system to perform that fix, if you want, I'd just need pointing to whatever repository y'all use for resources.whatwg.org |
| 22:58 | <Jeffrey Yasskin> | Looks like https://github.com/whatwg/whatwg.org/tree/main/resources.whatwg.org? |
| 22:58 | <TabAtkins> | ah, whatwg/whatwg.org, kk |
| 23:00 | <TabAtkins> | Actually, hm, I think it's just tweaking the whatwg boilerplates, actually. |
| 23:00 | <TabAtkins> | Anyway, Domenic, if you're okay with me doing that I'd be happy to. Like I said, you can spend more time on a different solution later if you'd like. |
| 23:13 | <TabAtkins> | Unless you say something to the contrary I'll do it on Wednesday. |