07:30
<Julian Descottes>

Hi, I'm working on the WebDriver BiDi implementation in Firefox, and I'm looking at the WebDriver BiDi download started triggered from the HTML spec (step 5.4.4 of https://html.spec.whatwg.org/#attempt-to-populate-the-history-entry's-document). I have a couple of questions around this (spawned from https://github.com/w3c/webdriver-bidi/issues/980).

First, do I understand correctly that this is not triggered when users click on a link with a download attribute? (which goes through https://html.spec.whatwg.org/#downloading-hyperlinks).
Then if that's correct, I would like to change this so that we also trigger the BiDi hook in case of a download attribute. But then I'm not sure there would be a navigation id relevant to send to BiDi in this case?

(I can also file an issue on GitHub if preferable to discuss about this)

07:35
<annevk>
Julian Descottes: there's an existing issue of the download attribute not being described in terms of the navigate algorithm. That would fix your issue. Are there other WebDriver callbacks that happen before or after this is called that also require the navigation ID? Because if not I suppose we could just generate a synthetic one in the download attribute algorithm as a workaround for now, but it's not great overall.
07:37
<Julian Descottes>
annevk: ok, great. And no the navigation id from this particular event is not really meant to be reused or shared with other events, it's more for completeness. So the workaround would be fine, but we could also make it optional on the BiDi side and omit the info until the HTML spec is fixed.
07:38
<Julian Descottes>
do you have a link to the issue about the download attribute?
07:44
<annevk>
Julian Descottes: https://github.com/whatwg/html/issues/5548 might be the most canonical one, but there's several. 😅
09:39
<zcorpan>
annevk: OK if I resurrect https://github.com/whatwg/html/pull/2480 ?
09:42
<annevk>
zcorpan: please!
09:43
<zcorpan>

annevk: do you remember details of this comment? https://github.com/mozilla/standards-positions/issues/466#issuecomment-745120322

Is the no-referrer-based redaction not sufficient?

09:50
<annevk>
zcorpan: I think if the redaction is based on the policies of the embedding elements (with their node document policies as fallback) it's probably good. (Modulo the debate as to whether an HTTP-level policy needs to override, but that can probably be kept as its own issue that might impact the behavior here down the line.)
09:57
<annevk>

zcorpan: ah

This is even further complicated when an embedded site is navigated as the site being navigated to would never know about its parent (other than that one exists).

is a case where we start exposing more information and also more strongly conveys that referrer policy now has this dual purpose. I think that's probably all okay though and it's relatively straightforward to follow.

09:59
<annevk>
zcorpan: my PR seems wrong in that it stores the referrer rather than some computed version of the referrer policy.
10:00
<zcorpan>
annevk: OK thanks. I'll start with rebasing
13:08
<zcorpan>
Hmm, no spec preview in https://github.com/whatwg/html/pull/11560
20:44
<Eric Portis (he/him)>
zcorpan: I wrote a draft blog post about repeating sizes within picture (and the sizes=auto special case, and why it should be extended). Any thoughts/feedback before I polish & publish? https://gist.github.com/eeeps/1ed57ba4c16c61e5ec6e9400d242da28