17:02:25 RRSAgent has joined #webdriver 17:02:25 logging to https://www.w3.org/2020/12/09-webdriver-irc 17:02:30 Is the Zoom meeting happening? The link doesn't seem to work. 17:02:31 Zakim has joined #webdriver 17:02:44 drousso has joined #webdriver 17:03:01 brwalder: https://browserstack.zoom.us/j/95359479872?pwd=OWs3eE1RbXdrM1V2Rk5CcG5zSWpNQT09 17:03:24 Honza has joined #webdriver 17:03:24 Thanks, new link works 17:03:43 present+ 17:03:45 sorry what is the new link? 17:03:49 Zakim: This is WebDriver-BiDi 17:03:50 https://browserstack.zoom.us/j/95359479872?pwd=OWs3eE1RbXdrM1V2Rk5CcG5zSWpNQT09 17:04:01 Meeting: WebDriver-BiDi 17:04:02 present+ 17:04:09 present+ 17:04:10 Chair: AutomatedTester 17:04:12 drousso_ has joined #webdriver 17:04:21 Thank you 17:04:23 Agenda: https://www.w3.org/wiki/WebDriver/2020-12-BiDi#Agenda 17:04:32 present+ 17:05:06 present+ 17:05:09 present+ 17:05:12 q? 17:05:22 RRSAgent: Make logs public 17:05:26 diemol has joined #webdriver 17:05:28 present+ 17:05:28 RRSAgent: Make minutes v2 17:05:28 I have made the request to generate https://www.w3.org/2020/12/09-webdriver-minutes.html jgraham 17:05:36 present+ 17:05:38 https://www.w3.org/wiki/WebDriver/2020-12-BiDi#Agenda 17:06:13 scribe: AutomatedTester 17:06:51 Topic: Follow up / reminders from last meeting 17:08:00 AutomatedTester No items to be discussed that aren't in the agenda already 17:08:01 ScribeNick: jgraham 17:08:13 Topic: Working Group Charter 17:08:29 AutomatedTester: Charter expires at end of the month 17:09:00 AutomatedTester: Recharter required to move forward. WebDriver-BiDi deliverable is current priority. 17:10:00 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? 17:10:21 mathiasbynens: What has W3C been doing to help up to now? 17:11:46 https://www.w3.org/2018/12/browser-testing-tools.html 17:11:47 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. 17:11:57 q+ 17:12:05 sadym_ has joined #webdriver 17:12:32 AutomatedTester: Patent Policy doesn't generate a lot of work. 17:12:47 q? 17:12:49 ack jgraham 17:13:47 john_chen has joined #webdriver 17:14:25 sadym_ has left #webdriver 17:14:42 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 17:15:54 Zakim, who's here? 17:15:54 Present: mathiasbynens, shengfa, drousso, Honza, brwalder, jgraham, AutomatedTester, diemol 17:15:56 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 17:15:56 On IRC I see john_chen, diemol, drousso_, Honza, drousso, Zakim, RRSAgent, brwalder, shengfa, AutomatedTester, github-bot, mkwst, jcraig, spectranaut, zcorpan, jgraham, cbiesinger, 17:15:56 ... odejesush99, heejin_, cb, mankyKitty, sah, NavidZ_, mattl, rbyers, JohnJansen, foolip, kereliuk, scheib, smcgruer_[EST], mathiasbynens, falken_, ella, whimboo, lukebjerring, 17:15:56 ... brrian, MikeSmith, logbot, gsnedders 17:16:00 jimevans has joined #webdriver 17:16:24 q? 17:16:26 AutomatedTester: Sense there's initial buy-in, futher actions will be by email 17:16:33 ScribeNick: AutomatedTester 17:16:34 not on the call, but we'd prefer it to stay in a WG 17:17:02 topic: Spec status updates 17:17:32 jgraham: there are currently 3 open PRs on the spec 17:17:48 ... Contexts https://github.com/w3c/webdriver-bidi/pull/62 17:18:17 ... this module has had a lot of review and should be landed soon 17:18:50 ... [describes when contexts are discarded] 17:19:20 ... there is an issue around this for top level context relate to 1:1 to tabs 17:19:43 ... this was fine until cross origin (missed what was said) 17:20:09 ... there is an open question around this that we need to resolve 17:20:13 sadym__ has joined #webdriver 17:21:08 ... the other item on context, we need to update other specs to give them more detailed items that they have glossed over 17:21:14 q? 17:21:41 ...Realms https://github.com/w3c/webdriver-bidi/pull/70 17:22:02 ... this talks about events when realms where created but noit when they are destroyed 17:22:14 ... and this needs follow up 17:22:25 ... Logging https://github.com/w3c/webdriver-bidi/pull/73 17:22:47 ... this is the first module that works well and allows us to showcase the work 17:22:53 ... this is different to cdp 17:23:12 ... it has only 1 type of event where cdp has 3+ 17:23:34 ... the PR only coveres console and js exceptions 17:23:52 ... I would appreciate reviews from other members on these 17:23:58 q? 17:24:28 topic: Event delivery on subscribe and filtering 17:24:29 present+ 17:24:57 jgraham: this is one of main issues with the current spec text 17:25:15 ... when you subscribe to events in the way the spec has been written 17:25:36 present+ 17:25:38 ... there is a race condition from subscribing of events and events happening 17:26:18 ... e.g. in devtools if you open the console it will show all the previous messages nad not just from that point 17:26:29 PR: https://github.com/w3c/webdriver-bidi/issues/72 17:26:49 ... so you can easily miss events 17:27:19 ... the way that CDP solves this is that it emits events when you enable 17:27:30 and has all the items 17:28:04 ... the contention is that we need to have something that is not a regression to existing protocols 17:28:57 ... one of the problems that I see we have set up very granular filtering do we need to reapply the filtering 17:29:52 ... so what is our strategy to allow clients to get the events they want exactly once with race conditions 17:29:55 q+ 17:30:07 ack brwalder 17:30:26 brwalder: So doing what CDP does here is one option 17:30:44 ... we could track the events that we would have fired 17:31:29 ... the race condition is made worse because need to have the relevant browsering contexts 17:31:37 ... and then trying to apply filtering 17:31:48 ... one solution could be to have the filtering done wit 17:31:57 ... out the id 17:32:14 jgraham: that could work if people subscribe to events globally 17:32:30 ... there is a quiestion around use cases 17:32:46 ... do we want to connect to a current browser 17:33:21 q+ 17:33:40 ... I think we want to have a mechanism to construct a way to get events you may have missed 17:33:44 ack brwalder 17:34:08 q+ 17:34:52 brwalder: there are 2 types of contexts here ...ones the automator creates and the ones the browser starts 17:35:05 ... e.g. webworkers or popups 17:35:54 ... [describes url filtering] 17:35:58 q? 17:36:07 ack shengfa 17:37:27 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 17:37:32 jgraham: that makes sense 17:37:57 ... I think we already have a mechanism to filter duplicates 17:38:29 ... my concern for existing CDP clients is they dont need to do this now so I dont see people wanting to move across 17:39:01 shengfa: one differenvce between us and CDP is that we want to send a list of browsing context. CDP just sends you everything 17:39:21 ... I can't see how we can avoid the race so we need to do something 17:39:27 jgraham: I agree 17:40:10 ... 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 17:40:37 shengfa: in that case that might be with minimal changes. 17:41:10 ... the client could ask for a specific sequence number and the remote end sends that and all the future events 17:41:30 q+ 17:41:37 jgraham: that's interesting... I would how much buffering we would need to do 17:42:35 ... [describes a possible issue with 2 browsing contexts] 17:44:04 ... [describes how filtering and buffering might work] 17:44:30 q? 17:44:57 ack brwalder 17:45:39 brwalder: I like the idea from shengfa about a sequence number that the client 17:46:10 ... but I am not sure if we need to do this since the remote end knows what it last sent 17:46:47 ... so we can do just send from the buffer 17:46:59 q+ 17:47:08 jgraham: yes, that's what I was trying to explain 17:47:26 ... it sounds complicated but not impossible 17:48:17 brwalder: We may need to have a way to buffer certain events 17:48:36 .. and for the rest we can regenerate them on demand 17:48:55 ... the key problem is that some of those events have already been emitted 17:49:59 jgraham: we are going to have some state here to keep track of where we are 17:50:31 ... [describes being subscribed to a child ifraame aand then subscribin to a top level context] 17:51:05 brwalder: I think if we are going to have something similar to CDP will allow easier adoption 17:51:21 ... I am not sure what the use cases are here 17:51:22 q? 17:51:54 shengfa: It might be difficult to support every edge case 17:52:08 ... I think it's better to have a soltion for each specific case 17:52:41 ... we need to have 2 types of events. One thats buffered and one that isnt 17:53:49 q? 17:53:57 ack shengfa 17:54:50 Topic: Design principles 17:55:03 https://github.com/w3c/webdriver-bidi/issues/78 17:55:36 jgraham: foolip has filed an issue about the design constrants we know but but it's not written down anywhere 17:55:59 ... and there are some assumptions that we haven't got written down 17:56:20 ... so we've written this down 17:56:57 s/we've written this down/we haven't written this down/ 17:57:24 ... so the question for this group is do we think that this is useful for our time and effort to write this down 17:58:31 brwalder: so do we use the issue for gathering? 17:58:34 jgraham: yes please 17:59:28 RRSAgent: Make minutes v2 17:59:28 I have made the request to generate https://www.w3.org/2020/12/09-webdriver-minutes.html jgraham 18:00:22 RRSAgent: bye 18:00:22 I see no action items