Meeting minutes
<brwalder> Is the Zoom meeting happening? The link doesn't seem to work.
<jgraham> brwalder: https://
<shengfa> Thanks, new link works
<Honza> sorry what is the new link?
<jgraham> Zakim: This is WebDriver-BiDi
https://
<Honza> Thank you
<jgraham> RRSAgent: Make logs public
<jgraham> RRSAgent: Make minutes v2
Follow up / reminders from last meeting
AutomatedTester No items to be discussed that aren't in the agenda already
Working Group Charter
AutomatedTester: Charter expires at end of the month
AutomatedTester: Recharter required to move forward. WebDriver-BiDi deliverable is current priority.
AutomatedTester: Does group see value in continuing as a Working Group, or is there a preference to move to a IG? Would mean we don't get staff support and aren't working under patent policy. Still value in being a WG?
mathiasbynens: What has W3C been doing to help up to now?
<AutomatedTester> https://
AutomatedTester: W3C doesn't provide a lot of staff time. Patency policy is the main benefit. Can help with external problems. Get 0.05 of MikeSmith's time.
AutomatedTester: Patent Policy doesn't generate a lot of work.
jgraham: Doesn't make sense to work as an IG. We have a standards track document that has interest from multiple vendors. Makes sense to remain on standards track
AutomatedTester: Will follow up in an email. We are delivering a specification that will have to go through the Process, so we will need to be a working group at some point in the future. Seems better to renew charter to focus on current deliverables. Need to work with MikeSmith and plh on details
AutomatedTester: Sense there's initial buy-in, futher actions will be by email
<gsnedders> not on the call, but we'd prefer it to stay in a WG
Spec status updates
jgraham: there are currently 3 open PRs on the spec
… Contexts https://
… this module has had a lot of review and should be landed soon
… [describes when contexts are discarded]
… there is an issue around this for top level context relate to 1:1 to tabs
… this was fine until cross origin (missed what was said)
… there is an open question around this that we need to resolve
… the other item on context, we need to update other specs to give them more detailed items that they have glossed over
… Realms https://
… this talks about events when realms where created but noit when they are destroyed
… and this needs follow up
… Logging https://
… this is the first module that works well and allows us to showcase the work
… this is different to cdp
… it has only 1 type of event where cdp has 3+
… the PR only coveres console and js exceptions
… I would appreciate reviews from other members on these
Event delivery on subscribe and filtering
jgraham: this is one of main issues with the current spec text
… when you subscribe to events in the way the spec has been written
… there is a race condition from subscribing of events and events happening
… e.g. in devtools if you open the console it will show all the previous messages nad not just from that point
PR: https://
… so you can easily miss events
… the way that CDP solves this is that it emits events when you enable
and has all the items
… the contention is that we need to have something that is not a regression to existing protocols
… one of the problems that I see we have set up very granular filtering do we need to reapply the filtering
… so what is our strategy to allow clients to get the events they want exactly once with race conditions
brwalder: So doing what CDP does here is one option
… we could track the events that we would have fired
… the race condition is made worse because need to have the relevant browsering contexts
… and then trying to apply filtering
… one solution could be to have the filtering done wit
… out the id
jgraham: that could work if people subscribe to events globally
… there is a quiestion around use cases
… do we want to connect to a current browser
… I think we want to have a mechanism to construct a way to get events you may have missed
brwalder: there are 2 types of contexts here ...ones the automator creates and the ones the browser starts
… e.g. webworkers or popups
… [describes url filtering]
shengfa: I think for the specific caase for browsing context. On the remote end we can keep a list of these contexts. For the events we can have a sequence number so that they could see which events are duplicated
jgraham: that makes sense
… I think we already have a mechanism to filter duplicates
… my concern for existing CDP clients is they dont need to do this now so I dont see people wanting to move across
shengfa: one differenvce between us and CDP is that we want to send a list of browsing context. CDP just sends you everything
… I can't see how we can avoid the race so we need to do something
jgraham: I agree
… what I would like to be is that if you dont ask for a list of contexts that you can still see what events have happened
shengfa: in that case that might be with minimal changes.
… the client could ask for a specific sequence number and the remote end sends that and all the future events
jgraham: that's interesting... I would how much buffering we would need to do
… [describes a possible issue with 2 browsing contexts]
… [describes how filtering and buffering might work]
brwalder: I like the idea from shengfa about a sequence number that the client
… but I am not sure if we need to do this since the remote end knows what it last sent
… so we can do just send from the buffer
jgraham: yes, that's what I was trying to explain
… it sounds complicated but not impossible
brwalder: We may need to have a way to buffer certain events
… and for the rest we can regenerate them on demand
… the key problem is that some of those events have already been emitted
jgraham: we are going to have some state here to keep track of where we are
… [describes being subscribed to a child ifraame aand then subscribin to a top level context]
brwalder: I think if we are going to have something similar to CDP will allow easier adoption
… I am not sure what the use cases are here
shengfa: It might be difficult to support every edge case
… I think it's better to have a soltion for each specific case
… we need to have 2 types of events. One thats buffered and one that isnt
Design principles
https://
jgraham: foolip has filed an issue about the design constrants we know but but it's not written down anywhere
… and there are some assumptions that we haven't got written down
… so we haven't written this down
… so the question for this group is do we think that this is useful for our time and effort to write this down
brwalder: so do we use the issue for gathering?
jgraham: yes please
<jgraham> RRSAgent: Make minutes v2