TIL that if you’ve got the GitHub command-line tool installed, and you’re looking at a git commit history for a GitHub repo, then you take run gh browse with the commit hash, like this:

gh browse 12dd6fa8ca76bd3bdff0c65a0c5a84b3ca870c3d

…and it’ll open up https://github.com/whatwg/fetch/commit/12dd6fa8ca76bd3bdff0c65a0c5a84b3ca870c3d in your browser. (Maybe I already knew this but subsequently forgot…)

annevk: Now I begin to wonder if the parameters in all those Location member functions are misnamed — flipped. Specifically, the first parameter should rightly be named activeWindow (or something) and the second one should be named incumbentWindow (rather than firstWindow).

Does the code seem to make more sense to if it used those names?

Regardless, I can see now that I need to just do firstWindow.document()->urlForBindings() to get the right URL — rather than frame->tree().parent())->document()->urlForBindings(). So I’ll make that change, and push an update.

Hello everyone, we are updating the Fetch spec to add HTTPS-Upgrades. I've been thinking how HTTPS-Upgrades works with Service Workers and I gathered some thoughts in a doc (with a very short explanation of how HTTPS-Upgrades works):

https://docs.google.com/document/d/1J5AkicHtSsCq2YVzLYwcFNj27Ah0-9VVTvkyevYxxPQ/edit

So far my conclusion is that:

• HTTPS-Upgrades is a navigation only feature. It doesn't modify subresource fetches.
• SWs can't intercept http:// navigations (since they are almost always cross origin). They can intercept http:// subresource fetches.
• Therefore, we don't need special handling of HTTPS-Ugprades in SWs. We might need to clear the "is HTTPS upgrade" boolean when the navigation completes successfully, but besides that, we shouldn't need to handle HTTPS-Upgrade fallbacks or any other error cases.

Does this sound reasonable? Please feel free to leave comments on the doc as well.