Meeting minutes
<jrandolf> present
ScribeMick: jgraham
Generate browser-compat-data from CDDL
github: w3c/
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.
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.
whimboo: Would like to get some feedback on this. We could start with some manual work if that's easier.
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.
whimboo: The main question is whether this would be useful at all.
<whimboo> whimboo: everyone of us would have to update the json files for the release versions in their browser
MaksimSadym: Are we talking about generating JSON from the spec, or about the browser returning the protocol version it supports?
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.
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.
jgraham: BCD already exists. The request is to be able to generate that specific format from the CDDL
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?
<whimboo> current source of BiDi support comes from https://
jgraham: No, the point is which version of the browser first implements a BiDi feature
<jrandolf> Good point
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.
gsnedders: The current BiDi implementations use CDDL directly? [not really]
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.
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.
Backward compatibility for "get coordinates relative to an origin" fails for "wheel.scroll" actions and a "pointer" origin
<gsnedders> We could presumably also just mechanically try running commands and see if they return "unknown command".
Github: w3c/
<jrandolf> gsnedders: Mmm, indeed, we can have a cron job that tries this.
whimboo: Scroll needs coodindates, which makes it look like a pointer. Should we add wheel as a pointer type?
gsnedders: Does pointer events have something we can copy here?
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.
jgraham: We should have the discussion on the github issue.
jrandolf: Isn't scroll already based on the current point?
whimboo: For wheel input source there aren't coordinates, it's not synced with the pointer position.
jrandolf: Could we use the coordinates from mouse events?
jgraham: That seems unsafe, because it changes the behaviour of tests
gsnedders: What's the current behaviour?
[discussion of current behaviour]
jrandolf: Chromium seems to use current mouse position
gsnedders: I think SafariDriver probably does that too, but I'm not sure
whimboo: There could be multiple mice
gsnedders: Someone should write a test to demonstrate the current behaviour
whimboo: I wrote a test
whimboo: I'll comment on the issue with the current behaviours
Clarify how browsing context groups and sharedIds work?
github: w3c/
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?
<whimboo> gsnedders: > * <@gsnedders:mozilla.org> whimboo nothing in `webdriver/tests/classic/perform_actions/wheel.py` seems to check `clientX`/`clientY`
<whimboo> strange. I will check later when I'm back. Have to run now
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
that can reach each other
Maksim Sadym: in classic you can reference only elements in the same browsing context, right?
jgraham (IRC): correct
Maksim Sadym: if you get an element by bidi and try to use it with classic, should it work?
Maksim Sadym: Want to make sure this is expected behavior and will check the spec
jgraham (IRC): behavior in classic is that you can only return and use elements from the same browsing context. BiDi is more flexible
Maksim Sadym: So we don't allow to reference bidi links in classic if it's in another browsing context?
jgraham (IRC): correct
Sam Sneddon [:gsnedders]: if you change classic's bc to be the correct frame or window you can use the reference from bidi
jgraham (IRC): yes, ids are global, classic will just check it's an element of the current doc
Clarify `script.addPreloadScript` behavior with a duplicated `context` in `contexts`.
<jgraham> github: w3c/
<jgraham> Topics: Cookies status
<jgraham> github: w3c/
jgraham (IRC): What is the status of cookies PR
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.
Sam Sneddon [:gsnedders]: Will take a look or will find someone
Maksim Sadym: Partition key: do we get the actual cookie partition or do we just get the filter provided.
jgraham (IRC): All cookies should be in the same partition of the cookie store. But if chrome works differently we should change that
Sam Sneddon [:gsnedders]: 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
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
<gsnedders> passed as an argument./
Maksim Sadym: can proceed with current approach. No critical issue from implementation perspective
Sam Sneddon [:gsnedders]: other question: in cases where cookies are not sent to 3rd party contexts (eg currently Safari, depending on the Storage Access API), people will want to know if cookies where sent to frames.
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.
Could have isStorageAccess key as part of the partition key. Should comment on the issue
Sam Sneddon [:gsnedders]: need to come to a conclusion whether what we want to do storage api should block the cookies api
jgraham (IRC): Someone from apple should look at it and say if the basic design is good enough
jgraham (IRC): Maksim should do a concrete proposal for different partition keys
Maksim Sadym: not a blocker, we can proceed
<jgraham> RRSAgent: make logs public
<jgraham> RRSAgent: make minutes