– DRAFT –
(MEETING TITLE)

browsingContext.downloadWillBegin should be emitted for links with a download attribute?

w3c/webdriver-bidi#980

<whimboo> github topic: w3c/webdriver-bidi#980

<whimboo> RRSAgent: make minutes

<whimboo> make minutes

<whimboo> make minutes

<whimboo> RRSAgent: make minutes

jdescottes: spec don't respect `download` attribute on links. We propose to emit download events.

jdescottes: question is do we want to add navigation information fo such downloads from the links, and if so, what it should be

sadym: it seems to be logical to have a new navigation ID and the URL of the dowanloadable content

whimboo: what should happen if user clicks a link with download attribute which leads to redirect

jimevans: we want to capture all the downloads including those started by `download` attribute. WRT redirects, IDK what is the right answer

jdescottes: in case of download link, do we want to push history state, or generate a fake navigation?

jimevans: when you click on the link with download, does it add an entry to the browser history when you click "backward-forward"? If it does not, we probably hsould not.

jimevans: when you click on the link with download, does it add an entry to the browser history when you click "backward-forward"? If it does not, we probably should not.

jdescottes: it does not create links with download attribute, but IDK if it does for links with `download` header attribute

AI: I will test it and follow up in the issue

jimevans: for me as one who writes the test, I expect the history exposed to the test to mimic the history in the real browser.

github topic: w3c/webdriver-bidi#982

<whimboo> RRSAgent: make minutes

jdescottes: when you download the link several times, it adds a counter, however Chrome does not expose that real filename. Should we expose the real filename? Are we OK with exposing the real filename?

sadym: it probably a bug in Chrome, but IDK if we can fix it

whimboo: we can expose the name at the moment the download finished

we should know the filename by that time

jdescottes: from Firefox point of view, we have the information early. The question is if we want to send that information earlier. From our side both approaches are fine.

I'm going to update WPT tests to avoid running into this issue

github topic: w3c/webdriver-bidi#983

jdescottes: Chrome prohibits some headers in `continue request` are prohibited, like `Host`. This creates critical differences in browsers' behavior.

<jdescottes> https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/header_util.cc;l=32-61;drc=98344435860d41977208fb875298162993ea091f

accroding to the spec, we should update them

sadym: from Chrome perspective, we have some workarounds for some headers like Referer, but IDK about Host. We should consider data from the BiDi client safe, and provide whatever they want to.

jdescottes: I'm going to check if it works like that wit hCDP

jdescottes: I'm going to check if it works like that with CDP

let's continue discussion in the issue

next topic: w3c/webdriver-bidi#948

sadym: feature requested by users is setting network conditions. Started with offline mode. Technically can be done with Network Interception. Will be difficult to specify bandwidth etc.

sadym: talking about offline: several aspects : network requests and navigator online. With network interception we cannot influence navigator online, bur we can handle requests

sadym: currently navigator online is defined in a way which should return false if the user can't reach the network. Unclear behavior

sadym: proposal is to add a hook `is offline` so that the html spec can call this to know what to return

jdescottes: hook for html spec sounds good to me, especially since we can't block all network for now

sadym: should we split or land everything in one PR

jimevans: can be more work, but I would prefer to see the full implementation landed at once. I would expect everything to behave as offline/online when setting this emulation.

sadym: sounds good

next topic: w3c/webdriver-bidi#968

github topic: w3c/webdriver-bidi#968

jdescottes: using continue with auth will store credentials. They will be reused for next requests. Can be annoying for testing authentication in details? Do we want to add a way to clear credentials, or to avoid storing credentials

sadym: trying to find where they are stored

jdescottes: see https://fetch.spec.whatwg.org/#biblio-http:~:text=If%20isAuthenticationFetch%20is%20true%2C%20then%20create%20an%20authentication%20entry%20for%20request%20and%20the%20given%20realm%2E this is where the authentication entry is created

jdescottes: is it interesting to be able to clear credentials?

jimevans: can be interesting, not sure if that should be a flag on the command or a separate command.

sadym: no scenarios are blocked on this you can always create another user context etc...

jdescottes: correct

jimevans: a clear credentials sounds preferable, this way we can stay close to what the browser would normally do. But a way to clear the credentials would be useful

sadym: can users clear their tokens via UI?

jimevans: probably and we should have a way to replicate that with the test

next topic: Note about unsubscribing and getting rid of user contexts

jimevans: there is a note about getting rid of user contexts when unsubscribing, we should do it asap

jimevans: it's in https://www.w3.org/TR/webdriver-bidi/#type-session-UnsubscribeByAttributesRequest

jimevans: will file an issue

make minutes

RRSAgent: make minutes