16:59:33 <RRSAgent> RRSAgent has joined #webdriver
16:59:37 <RRSAgent> logging to https://www.w3.org/2023/12/13-webdriver-irc
16:59:38 <Zakim> Zakim has joined #webdriver
17:00:23 <jrandolf> present
17:00:45 <jrandolf> present+
17:01:34 <jgraham> Meeting: WebDriver BIDi
17:01:45 <JimEvans> present+
17:01:50 <jgraham> Agenda: https://www.w3.org/wiki/WebDriver/2023-12-BiDi#Agenda
17:03:44 <MaksimSadym> present+
17:03:46 <jgraham> CHair: jgraham
17:03:52 <jrandolf> present+
17:03:53 <jgraham> ScribeMick: jgraham
17:03:59 <jgraham> ScribeNick: jgraham
17:04:01 <lola_> lola_ has joined #webdriver
17:04:03 <jgraham> present+
17:04:03 <whimboo> present+
17:04:04 <lola_> present+
17:04:12 <lightning00blade> present+
17:04:16 <sasha> present+
17:04:17 <jgraham> Topic: Generate browser-compat-data from CDDL
17:05:57 <jdescottes> present+
17:06:34 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/619
17:07:21 <jgraham> whimboo: A while ago I asked about documenting APIs on MDN. We delayed this. Classic has a few commands documented. Might not be trivial to document everything, but we could focus first on BCD. This would allow filling in the tables on MDN with compatibility across versions. Clients could also use this data. This would be a good start for documentation. Tools like e.g. VSCode could also consume it.
17:07:31 <cb> cb has joined #webdriver
17:08:01 <jgraham> whimboo: All the data is in JSON files. Might be work to manually create it. But we have CDDL blocks which are used to generate TS in the Chromium implementation. We could maybe use that generation code to generate BCD data and keep it up to date.
17:08:07 <cb> present+
17:08:28 <jgraham> whimboo: Would like to get some feedback on this. We could start with some manual work if that's easier.
17:08:31 <jgraham> q?
17:08:37 <jrandolf> q+
17:08:42 <jgraham> ack next
17:09:00 <MaksimSadym> q+
17:10:10 <jgraham> jrandolf: CDDL has a native representation for JSON. The tool for generating TS is not canonical, but there is one for JSON. The parser can validate JSON files. I'm not sure if the tool fits for this scenario.
17:10:26 <cb> q+
17:10:48 <jgraham> whimboo: The main question is whether this would be useful at all.
17:11:03 <jgraham> ack next
17:11:30 <whimboo> whimboo: everyone of us would have to update the json files for the release versions in their browser
17:12:05 <jgraham> MaksimSadym: Are we talking about generating JSON from the spec, or about the browser returning the protocol version it supports?
17:13:12 <jgraham> whimboo: we need a list of all the commands and events that we support. Generating full documentation is harder. Would like to know which version of the browser implements each API.
17:13:17 <jgraham> ack next
17:13:18 <jrandolf> q+
17:14:18 <jgraham> cb: From the client perspective this would be very helpful either as a file or as an endpoint in the driver. In the client we could help them understand why a command isn't working.
17:14:29 <gsnedders> q+
17:15:26 <jgraham> jgraham: BCD already exists. The request is to be able to generate that specific format from the CDDL
17:15:30 <jgraham> ack nex
17:15:32 <jgraham> ack next
17:16:49 <jgraham> jrandolf: The problem to solve is building a browser compat table? Isn't the point of these meetings to standardise and implement everything in BiDi? What do these files actually specify? That someone doesn't implement a specific feature?
17:16:55 <whimboo> current source of BiDi support comes from https://docs.google.com/spreadsheets/d/1bkiPU5eDBCqFkx5p_VSBx_OK8gy9TeHRKQVPHKMATGQ/edit?pli=1#gid=0
17:18:05 <jgraham> jgraham: No, the point is which version of the browser first implements a BiDi feature
17:18:40 <jrandolf> Good point
17:19:01 <jgraham> gsnedders: Other specs might also define custom extension points e.g. permissions. In a browser that didn't support permissions that extension wouldn't be implemented, and that's useful to document. Might add more features in the future and existing implementations might not support them.
17:19:34 <jgraham> gsnedders: The current BiDi implementations use CDDL directly? [not really]
17:20:31 <jrandolf> q+
17:20:54 <jgraham> gsnedders: So there's not just a way to get the copy of the CDDL emedded in the browser version to work out which APIs are being implemented. But we could generate empty implementations from the spec and maybe automatically add browser data from implementations that use CDDL directly.
17:21:00 <jgraham> ack next
17:21:19 <jgraham> ack next
17:21:53 <jgraham> jrandolf: I think it would be nice if other vendors also used the CDDL as a way to version what they do. Could use that to generate a compat table if they trim the CDDL to what they support.
17:22:27 <jgraham> Topic: Backward compatibility for "get coordinates relative to an origin" fails for "wheel.scroll" actions and a "pointer" origin
17:22:28 <gsnedders> We could presumably also just mechanically try running commands and see if they return "unknown command".
17:22:35 <jgraham> Github: https://github.com/w3c/webdriver/issues/1758
17:23:12 <jrandolf> gsnedders: Mmm, indeed, we can have a cron job that tries this.
17:23:24 <jgraham> whimboo: Scroll needs coodindates, which makes it look like a pointer. Should we add wheel as a pointer type?
17:23:50 <jgraham> gsnedders: Does pointer events have something we can copy here?
17:25:23 <jgraham> jgraham: This only makes sense for mouse-type pointers I think. Easiest might be to just add coordinates to scroll and if you want it in sync with the pointer position you have to do that manually.
17:25:52 <jrandolf> q+
17:25:52 <jgraham> jgraham: We should have the discussion on the github issue.
17:25:56 <jgraham> ack next
17:26:07 <jgraham> jrandolf: Isn't scroll already based on the current point?
17:26:28 <jgraham> whimboo: For wheel input source there aren't coordinates, it's not synced with the pointer position.
17:26:43 <jgraham> jrandolf: Could we use the coordinates from mouse events?
17:27:40 <jgraham> jgraham: That seems unsafe, because it changes the behaviour of tests
17:27:56 <jgraham> gsnedders: What's the current behaviour?
17:29:53 <jgraham> [discussion of current behaviour]
17:30:23 <jgraham> jrandolf: Chromium seems to use current mouse position
17:30:39 <jgraham> gsnedders: I think SafariDriver probably does that too, but I'm not sure
17:30:47 <jgraham> whimboo: There could be multiple mice
17:31:42 <jgraham> gsnedders: Someone should write a test to demonstrate the current behaviour
17:31:45 <jgraham> whimboo: I wrote a test
17:32:22 <jgraham> whimboo: I'll comment on the issue with the current behaviours
17:32:44 <jgraham> Topic: Clarify how browsing context groups and sharedIds work?
17:32:52 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/597
17:34:24 <jgraham> MaksimSadym: The specification uses Browsing Context group to talk about contexts that can access each other. But the HTML spec doesn't match that. Firefox allows accessing elements from multiple documents, but Chrome doesn't, what's correct here?
17:34:29 <jgraham> q+
17:34:51 <jgraham> ScribeNick: jdescottes
17:35:17 <whimboo> gsnedders: > * <@gsnedders:mozilla.org> whimboo nothing in `webdriver/tests/classic/perform_actions/wheel.py` seems to check `clientX`/`clientY`
17:35:17 <whimboo> strange. I will check later when I'm back. Have to run now
17:37:17 <jdescottes> jgraham (IRC): Spec is wrong as mentioned, because html changed def of browingcontext group. Documents in the same cluster can reach each other. They can access each others runtimes. It is intended that if you hae an element in a doc and return it, globals that can access this element should also be able to use the returned value. I think Firefox implementation is right, but spec needs to be updated. Shared ids are shared across all BCs
17:37:17 <jdescottes> that can reach each other
17:38:00 <jdescottes> Maksim Sadym: in classic you can reference only elements in the same browsing context, right?
17:38:18 <jdescottes> jgraham (IRC): correct
17:39:07 <jdescottes> Maksim Sadym: if you get an element by bidi and try to use it with classic, should it work?
17:40:05 <jdescottes> Maksim Sadym: Want to make sure this is expected behavior and will check the spec
17:40:56 <jdescottes> jgraham (IRC): behavior in classic is that you can only return and use elements from the same browsing context. BiDi is more flexible
17:41:26 <jdescottes> Maksim Sadym: So we don't allow to reference bidi links in classic if it's in another browsing context?
17:41:33 <jdescottes> jgraham (IRC): correct
17:42:11 <jdescottes> Sam Sneddon [:gsnedders]: if you change classic's bc to be the correct frame or window you can use the reference from bidi
17:42:49 <jdescottes> jgraham (IRC): yes, ids are global, classic will just check it's an element of the current doc
17:43:19 <jgraham> Topic: Clarify `script.addPreloadScript` behavior with a duplicated `context` in `contexts`.
17:43:29 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/617
17:44:14 <jgraham> Topics: Cookies status
17:44:29 <jgraham> github: https://github.com/w3c/webdriver-bidi/pull/501
17:45:05 <jdescottes> jgraham (IRC): What is the status of cookies PR
17:45:10 <jrandolf> q+
17:45:16 <jgraham> ack next
17:45:18 <MaksimSadym> q+
17:45:24 <jrandolf> q-
17:46:28 <jdescottes> Lola: PR in a good place. Mike has implemented feedback on the issues. Now, looking for non-mozilla, non-google feedback. Someone from Apple should have a look.
17:46:43 <jdescottes> Sam Sneddon [:gsnedders]: Will take a look or will find someone
17:46:47 <jgraham> ack next
17:47:26 <jgraham> q+
17:47:52 <jdescottes> Maksim Sadym: Partition key: do we get the actual cookie partition or do we just get the filter provided.
17:48:28 <jgraham> ack next
17:49:31 <lola_> lola_ has joined #webdriver
17:49:46 <jdescottes> jgraham (IRC): All cookies should be in the same partition of the cookie store. But if chrome works differently we should change that
17:50:36 <jgraham> q+
17:50:57 <jdescottes> Sam Sneddon [:gsnedders]: Not opposed to returning the partition key but might end up in a situation where browsers return what was passed
17:51:11 <jgraham> ack next
17:53:02 <jdescottes> jgraham (IRC): will not always return what was passed in because you pass a context. In short term, maybe easiest to return it for each cookie. It will add protocol overhead. Could have a base partition key, potentially updated by each cookie if needed. Pushes complexity on the client
17:53:02 <gsnedders> s/Not opposed to returning the partition key but might end up in a situation where browsers return what was passed/CHIPS, as Chrome is currently planning on shipping (or now shipping?), has different cookies having different partitions (or rather: some partitioned and some not). But we're probably moving towards all browsers having all cookies either partitioned or blocked, so we'd end up with every browser basically just returning what was
17:53:02 <gsnedders> passed as an argument./
17:53:27 <jdescottes> Maksim Sadym: can proceed with current approach. No critical issue from implementation perspective
17:54:51 <jgraham> q+
17:55:21 <jdescottes> Sam Sneddon [:gsnedders]: other question: in cases where cookies are not sent to 3rd party contexts (eg currently Safari), people will want to know if cookies where sent to frames.
17:55:34 <jgraham> ack next
17:55:49 <gsnedders> s/Safari/Safari, depending on the Storage Access API/
17:58:06 <jdescottes> jgraham (IRC): easiest way to tell is to intercept request and see where cookies are sent. Not clear if we need to add a feature to support this use case.
17:58:07 <jdescottes> Could have isStorageAccess key as part of the partition key. Should comment on the issue
17:59:31 <jdescottes> Sam Sneddon [:gsnedders]: need to come to a conclusion whether what we want to do storage api should block the cookies api
17:59:40 <jdescottes> jgraham (IRC): Someone from apple should look at it and say if the basic design is good enough
18:00:08 <jdescottes> jgraham (IRC): Maksim should do a concrete proposal for different partition keys
18:00:16 <jdescottes> Maksim Sadym: not a blocker, we can proceed
18:01:11 <jgraham> q?
18:01:16 <jgraham> RRSAgent: make logs public
18:01:20 <jgraham> RRSAgent: make minutes
18:01:21 <RRSAgent> I have made the request to generate https://www.w3.org/2023/12/13-webdriver-minutes.html jgraham
18:01:28 <jgraham> zakim, bye
18:01:28 <Zakim> leaving.  As of this point the attendees have been jrandolf, JimEvans, MaksimSadym, jgraham, whimboo, lola_, lightning00blade, sasha, jdescottes, cb
18:01:28 <Zakim> Zakim has left #webdriver
18:02:38 <jgraham> RRSAgent, bye
18:02:38 <RRSAgent> I see no action items