16:58:10 <RRSAgent> RRSAgent has joined #webdriver
16:58:10 <RRSAgent> logging to https://www.w3.org/2022/11/09-webdriver-irc
16:58:16 <jgraham> RRSAgent: stop
17:00:13 <jgraham> Meeting: WebDriver
17:00:28 <jgraham> Agenda: https://www.w3.org/wiki/WebDriver/2022-11-BiDi#Agenda
17:01:26 <jgraham> present+
17:01:46 <jdescottes> present+
17:02:07 <brwalder> brwalder has joined #webdriver
17:02:11 <JimEvans> present+
17:02:37 <jgraham> ScribeNick: brwalder
17:02:39 <brwalder> present+
17:02:52 <patrickangle_> present+
17:03:46 <simonstewart> simonstewart has joined #webdriver
17:04:28 <jgraham> topic: Network request logging
17:04:33 <AutomatedTester> present+
17:04:35 <jgraham> github: https://github.com/w3c/webdriver-bidi/pull/204
17:05:37 <brwalder> jgraham: PR is up. PR discussion has a list of current known issues.
17:05:39 <jgraham> https://github.com/w3c/webdriver-bidi/pull/204#issuecomment-1309011976
17:05:40 <sadym> present+
17:05:54 <sadym> have audio issues
17:05:56 <simonstewart> present+
17:06:30 <JimEvans> Am only here for a little bit; am boarding a flight in ~20 minutes.
17:07:52 <AutomatedTester> q+
17:07:59 <brwalder> jgraham: What invariants should we provide? Ideally we should get a beforeRequestSent before any other event. What happens if you subscribe in the middle of a request? Attempt to backfill, or ignore event stream?
17:08:01 <simonstewart> q+
17:08:19 <jgraham> ack AutomatedTester
17:08:29 <patrickangle_> q+
17:09:11 <brwalder> AutomatedTester: Most people just want to trigger a navigation and collect the resulting logs. Subscribing to network events mid-click seems like an edge case.
17:09:28 <AutomatedTester> ack next
17:09:28 <jgraham> ack simonstewart
17:10:51 <brwalder> simonstewart: Agree with David. You should just get events that were fired after you subscribe. If the goal is to implement interception, its already too late if you miss the initial event. If the goal is logging, it shouldn't matter.
17:10:58 <jgraham> ack patrickangle_
17:11:15 <cb> present+
17:11:49 <jgraham> q+
17:12:08 <brwalder> patrickangle: +1. Sending all events will be more predictable then hiding some.
17:12:10 <jgraham> ack jgraham
17:13:10 <patrickangle_> q+
17:13:24 <jgraham> ack patrickangle_
17:13:45 <brwalder> patrickangle: This is also how WebInspector works. If it's not open, it's not collecting logs.
17:15:57 <brwalder> jgraham: CDP has an initiator field that tells you whether a request came from the parser or from script. This concept isn't exposed in the platform so may be tricky to implement. Are there known use cases, such as Puppeteer?
17:17:12 <sadym> IDK
17:19:05 <brwalder> jgraham: See Github issue for other technical details that need clarity.
17:19:20 <jgraham> topic: Update spec to define things in terms of Navigables
17:19:30 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/91
17:22:19 <sadym> q+
17:23:09 <AutomatedTester> q+
17:23:16 <brwalder> jgraham: Navigables have been added to the HTML spec to represent a "window" that has history. We've been using browsing contexts for this concept so far. Navigables do a better job of expressing cross-origin navigations. Browsing contexts are more relevant for script where you care about what context code was evaluated in. Should we introduce the navigable concept to bidi and differentiate between these somehow?
17:23:19 <jgraham> ack sadym
17:24:01 <brwalder> sadym: Is there a 1:1 mapping between browsing context and document?
17:25:06 <brwalder> jgraham: A frame is a navigable because you can navigate a frame. A browsing context is 1:1 with a window proxy.
17:25:59 <jgraham> q?
17:26:03 <jgraham> ack AutomatedTester
17:27:04 <sadym> q+
17:27:08 <brwalder> AutomatedTester: How many clients are using bidi right now that could be broken by this change? Seems like this number is small so we should just make the change and notify clients.
17:27:15 <jgraham> ack sadym
17:27:54 <cb> WebdriverIO will have Bidi support with upcoming v8 release so from my side I think it will be fine to go with the breaking change.
17:28:13 <brwalder> sadym: Could we simply rename current usage of browsing context -> navigable and find a different name for browsing contexts?
17:28:54 <brwalder> jgraham: Yes this should be possible and could help implement this without a breaking change.
17:29:28 <sadym> q+
17:29:30 <brwalder> jgraham: Let's investigate soon and see if we can do this in a non-breaking way.
17:29:35 <jgraham> ack sadym
17:30:12 <brwalder> sadym: People who have started experimenting with bidi will be impacted by the change.
17:31:22 <brwalder> AutomatedTester: The Selenium community is creating some new clients for bidi and we have a short window to address this before the change becomes risky.
17:31:41 <jgraham> topic: Editorial meetings
17:32:19 <sadym> q+
17:32:52 <jgraham> ack sadym
17:32:59 <simonstewart> AutomatedTester: why not just recreate it anyway?
17:33:28 <jgraham> action: AutomatedTester to recreate the editorial meeting invite
17:33:59 <jgraham> topic: Clear log events buffer on document change
17:34:08 <jgraham> GitHub: https://github.com/w3c/webdriver-bidi/issues/312
17:34:26 <sadym> q+
17:35:34 <brwalder> jdescottes: Spec says to keep events for a document in a buffer and output these when the client subscribes. Tests assume the buffer will be cleared on navigation. Should we update the spec to match? Spec says to keep all events even if doc is reloaded.
17:35:38 <jgraham> ack sadym
17:36:16 <jgraham> q+
17:36:23 <brwalder> sadym: This is related to whether logs subscriptions will be based on navigables or browsing contexts/documents in the spec.
17:36:26 <jgraham> ack jgraham
17:36:26 <simonstewart> q+
17:37:18 <sadym> q+
17:37:38 <brwalder> jgraham: Deleting the logs is simple to do but does anyone have a use case for keeping the logs around?
17:37:45 <jgraham> ack simonstewart
17:38:32 <sadym> q-
17:38:38 <sadym> q+
17:38:48 <brwalder> simonstewart: We should make sure that any pending events are sent before a navigation occurs so that client don't miss events. We may need a command to manually clear the buffer for clients that really want a clean state before navigating.
17:39:02 <jgraham> ack sadym
17:41:05 <brwalder> jdescottes: No clear reason buffering was implemented the current way. It seemed more straightforward.
17:41:31 <brwalder> simonstewart: If we decide that navigating should flush the buffer, should some other events flush the buffer too?
17:42:09 <sadym> q+
17:42:58 <brwalder> jgraham: Buffering events from previous pages doesn't make sense for devtools where you care about the current page.
17:43:27 <patrickangle_> q+
17:43:30 <brwalder> jgraham: With automation, you probably do care about tracking everything.
17:44:25 <brwalder> simonstewart: Do we even need a buffer? Replaying events can lead to inconsistent state on the client.
17:46:33 <patrickangle_> q-
17:46:51 <brwalder> jgraham: Discussing scenarios for keeping logs.
17:47:43 <brwalder> sadym: Some users may care about logs from beginning of current page but not previous page. Buffer could be useful there.
17:48:25 <brwalder> simonstewart: Should events have an indicator that they are a buffered event and not a "live" event?
17:49:19 <jdescottes> q+
17:49:25 <brwalder> jgraham: Having a command to clear the buffer makes sense.
17:49:26 <sadym> q+
17:49:28 <jgraham> ack sadym
17:50:37 <brwalder> sadym: Subscribing and unsubscribing events should clear the buffer so we may not need a new command.
17:50:51 <jgraham> ack jdescottes
17:51:05 <brwalder> jgraham: sub/unsub forces all events to be sent over the wire, so won't be as convenient in a high latency situation.
17:51:17 <sadym> based on realm
17:51:36 <brwalder> jdescottes: To reimplement what devtools does, is there a way to know if an event is from the previous page or the live one?
17:52:21 <jgraham> q?
17:52:21 <brwalder> jgraham: You can use the realmId. Documents/navigables could also help if we use those in the spec.
17:53:11 <jgraham> Topic: Fix tests failures in Python 3.10+
17:53:27 <jgraham> GitHub: https://github.com/web-platform-tests/wpt/pull/36787
17:53:32 <brwalder> sadym: Can we do something about upgrading websockets library for Python?
17:55:16 <brwalder> jgraham: WPT has to support py 3.6. A lot of libraries, including websockets, are not compatible with 3.6 in their latest versions. Gecko is still using 3.6 in CI. This will take some effort to change.
17:55:19 <patrickangle_> q+
17:55:32 <jgraham> ack patrickangle_
17:56:07 <brwalder> patrickangle: Safari is using 3.9 since this is what macOS ships with.
17:56:53 <jgraham> q?
17:57:35 <jgraham> RRSAgent: make minutes
17:57:35 <RRSAgent> I have made the request to generate https://www.w3.org/2022/11/09-webdriver-minutes.html jgraham
17:57:40 <jgraham> zakim, bye
17:57:40 <Zakim> leaving.  As of this point the attendees have been jgraham, jdescottes, JimEvans, brwalder, patrickangle_, AutomatedTester, sadym, simonstewart, cb
17:57:40 <Zakim> Zakim has left #webdriver
17:58:09 <jgraham> RRSAgent: bye
17:58:09 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2022/11/09-webdriver-actions.rdf :
17:58:09 <RRSAgent> ACTION: AutomatedTester to recreate the editorial meeting invite [1]
17:58:09 <RRSAgent>   recorded in https://www.w3.org/2022/11/09-webdriver-irc#T17-33-28