15:56:34 RRSAgent has joined #webdriver 15:56:34 logging to https://www.w3.org/2021/06/09-webdriver-irc 15:56:38 Zakim has joined #webdriver 15:57:12 AutomatedTester_ has joined #webdriver 15:57:26 Meeting: WebDriver-BiDi 15:57:39 Chair: AutomatedTester 15:58:00 Agenda: https://www.w3.org/wiki/WebDriver/2021-06-BiDi#Agenda 15:58:10 ScribeNick: AutomatedTester 15:59:31 Honza has joined #webdriver 16:00:13 jdescottes has joined #webdriver 16:00:14 brwalder has joined #webdriver 16:01:06 jimevans has joined #webdriver 16:02:11 present+ 16:03:02 present+ 16:03:07 present+ 16:03:10 present+ 16:03:12 present+ 16:03:13 present+ 16:03:13 RRSAgent: Make minutes v2 16:03:13 I have made the request to generate https://www.w3.org/2021/06/09-webdriver-minutes.html jgraham 16:03:24 RRSAgent: Make logs public 16:03:43 present+ 16:04:49 topic: Web Extensions Community Group 16:05:00 simonstewart has joined #webdriver 16:05:18 jgraham (IRC): this is a FYI item 16:05:52 ... I think that this is relevant to this group as there are a lot of similarities between API surface for webextensions and bidi 16:06:01 ... e.g. sandbox JS execution 16:06:30 Regrets for the meeting happening now, I have other stuff I need to take care of I'm afraid. 16:06:56 AutomatedTester_ (IRC): Is there any documentation this group can read up on? 16:07:31 jgraham (IRC): I don't †hink anything has been released yet... I am mentioning as I think there is potential for collaboration between our group and their group 16:07:33 Charter: https://github.com/w3c/webextensions/blob/main/charter.md 16:08:14 q? 16:08:18 drousso has joined #webdriver 16:08:24 topic: Gecko implementation progress 16:08:28 present+ 16:08:40 present+ 16:08:41 Design doc: https://docs.google.com/document/d/1Of3ZhWIAwYXPezuG_hMpmTK7Nv1a9_E_VsnBWtD2nD8/edit 16:09:17 jgraham (IRC): The gecko team have sent out an intent to prototype webdriver bidi 16:09:37 https://groups.google.com/a/mozilla.org/g/dev-platform/c/kASQnIcU9Nc/m/v77WY5siBwAJ 16:09:41 ... we would love to have feedback on our design document 16:10:16 ... we would love to hear from people implementing the client maintainers to make sure this makes sense 16:10:31 ... any and all feedback is welcome! 16:10:35 q? 16:12:25 topic: context.navigate 16:12:28 github: https://github.com/w3c/webdriver-bidi/pull/93 16:13:04 jgraham (IRC): the next three items are are status updates and requests for feedback 16:13:30 ... foolip (IRC) has reviewed the html parts and hope to get that landed soon 16:13:43 ... and this is the last call for the bidi to get this landed soon 16:14:07 ... and there has been discussion about how the event ordering should be compared to the command returning 16:14:19 ...[gives example around load event] 16:15:12 ... this is important to know when a navigation has happened by the test or by something else 16:15:29 ... fragments are a special case as they are synchronous 16:16:46 ...[describes how things could return] 16:16:50 q? 16:17:02 github-bot (IRC): end topic 16:17:24 github-bot: end topic 16:17:56 topic: context.reload 16:18:00 github-bot (IRC): https://github.com/w3c/webdriver-bidi/issues/107 16:18:14 github: https://github.com/w3c/webdriver-bidi/issues/107 16:18:41 jgraham (IRC): there is a PR for reloading pages 16:18:57 ... I think this is largely straight forward 16:19:11 ... one feature that is in CDP is force reload 16:19:36 ... and HTML spec does not describe what a "force reload is" 16:19:57 ... [describes cases that are not obvious] 16:20:32 ... all browsers have this so I am assuming this is going to be simple but it could turn out to be not interoperable 16:20:50 q+ 16:21:09 q+ 16:21:15 q- 16:21:31 ... I have noted this in the PR as I think it's important to know but I don't think people are going to change how their browser works 16:21:32 q? 16:21:42 ack drousso 16:22:02 q+ 16:22:17 drousso (IRC): I just wanted to mention in safari that a force reload means reload and ignore all the caches 16:22:24 q+ 16:22:35 ack brwalder 16:23:20 brwalder (IRC): jgraham (IRC) I think you mentioned that force reload is in cdp but I can't see it, I just see ignore cache 16:23:33 jgraham (IRC): I think I assumed they are the same 16:24:05 jgraham (IRC): I can see there cases where "ignore the cache" might not mean what we think it is 16:24:09 ack whimboo 16:24:57 whimboo (IRC):are we only allowing this for top level browser context to match browsers 16:25:27 jgraham (IRC): I assumed it was any context and I don't think I have that limitation in the PR 16:25:51 ... is "reload a frame" a thing? 16:26:02 ... [no replies] 16:26:06 Yes, there is "Reload this Frame" action in Firefox 16:26:07 q? 16:26:25 that exists in Safari too 16:26:31 i think 😅 16:26:42 github-bot: end topic 16:26:45 nooooooo the shame 😭 16:27:12 topic : context.traverseHistory 16:27:14 github: https://github.com/w3c/webdriver-bidi/pull/109 16:27:29 github: https://github.com/w3c/webdriver-bidi/pull/109 16:27:33 topic: context.traverseHistory 16:27:49 github: https://github.com/w3c/webdriver-bidi/pull/109 16:28:29 jgraham (IRC): The third change is moving through history 16:28:42 ... I have a draft PR for the html spec changes we need 16:29:00 ... the model here is that you can move via a delta 16:29:38 ... this is different to CDP but the clients do this 16:29:57 ... and it is closer to what cypress does as other tools just have back/forward 16:30:29 ... and since there are things in the bfcache there might not be events that are returned to the user 16:30:31 q? 16:30:59 github-bot: end topic 16:31:21 topic: Stale Element Reference 16:31:26 github: https://github.com/w3c/webdriver/issues/1594 16:31:54 jgraham (IRC): this is a question that is for all webdriver 16:32:38 ... I understand there was a distinction in the past 16:33:07 q+ 16:33:14 ... the question is what is the expected lifetime... 16:34:27 ack simonstewart 16:35:04 simonstewart (IRC): The original plan was we kept a cache in the window global. 16:35:27 ... if you navigate away and come back it would nuke our cache 16:36:28 ... in watir and that they will do a lookup again but selenium doesnt do that and assumes the user knows what is the best wayt to handle this 16:36:39 jgraham (IRC): i think that is good 16:37:04 ... I think we need to read the webdriver spec and make sure it does what you have just said 16:37:54 ... my inclination is to not have something similar in bidi 16:38:10 q+ 16:38:33 ... and that in bidi we have more complex objects that are returned 16:38:52 ... and they can have large amounts of data that may get stored in a cache 16:38:59 ack simonstewart 16:39:46 simonstewart (IRC): I think it gets very interested... in webdriver http we required that they keep it instead of the client 16:40:05 ... as the browser would know the lifecycles better than a client 16:41:04 jgraham (IRC): my concern is if we return a handle and then it is gc'ed and someone tries to use it and it could return a differrent error 16:41:20 simonstewart (IRC): is this due to JS serialisation 16:41:35 jgraham (IRC): maybe... [discusses] 16:42:14 simonstewart (IRC): in webdriver http we essentially wanted something that could be returned that passed going through `json.stringify` 16:42:37 jgraham (IRC): [discusses JS execution and handles] 16:42:52 simonstewart (IRC): the original plan was due to things that lives in the DOM 16:43:29 jgraham (IRC): that leads to the question about what type of references we need to keep 16:44:13 ... one thing that I think is true in http spec but not bidi is... 16:44:58 ... if you disconnect an element from the DOM but it's still alive then we would return staleelement reference 16:45:30 ... but in JS the handle would still be held 16:45:53 ... [missed a few items around usage] 16:46:51 action: Verify Webdriver HTTP spec matches the requirements and clarify where necessary 16:47:01 github-bot: end topic 16:47:27 topic: Please review the client 16:47:31 github: https://github.com/web-platform-tests/wpt/pull/28381 16:48:42 jgraham (IRC): please review so we can get this landed soon so we can start writing wpt 16:49:01 topic: H2 Priorities 16:49:26 jgraham (IRC): this is part question and statement 16:49:46 ... in the spec we are now at a stage to allow parallel spec work 16:50:00 ... I am happy to help people get started with that 16:50:34 ... and moving forward, the next highest value task is `scriptExecution` 16:50:56 ... and there some good easy tasks like screenshots 16:51:13 aside: what does "H2" mean here? 16:51:18 ... and other low hanging fruit 16:52:32 ... [describes cases where we need to choose between cdp vs webdriver in this case] 16:52:42 q? 16:53:24 jgrahm: Other client priorities seem to be request logging and interception, and user input (could be based on WebDriver actions? Not clear what the requirements are) 16:54:22 automatedtester: what about setting wpt as a priority? and moving to requiring tests for spec changes 16:54:50 jgraham (IRC): yes, I think we can move towards that. We haven't done it yet as there is no client 16:55:00 q+ 16:55:28 RRSAgent: make minutes v2 16:55:28 I have made the request to generate https://www.w3.org/2021/06/09-webdriver-minutes.html jgraham 16:55:36 ... and there is no implementation as writing tests in a vacuum is hard 16:55:37 Chromium impl prototype: https://github.com/sadym-chromium/bidiInChromeContext 16:55:44 ack brwalder 16:55:58 RRSAgent: Make logs public 16:56:20 brwalder (IRC): there is a chromium prototype that sadym (IRC) has been working on 16:56:37 ... it's rough but we are starting 16:56:59 ... it doesn't do much 16:57:03 q? 16:59:07 RRSAgent: make minutes v2 16:59:07 I have made the request to generate https://www.w3.org/2021/06/09-webdriver-minutes.html jgraham 16:59:15 RRSAgent: stop