Meeting minutes
<jgraham> RRSAgent: stop
Network request logging
<jgraham> github: https://
jgraham: PR is up. PR discussion has a list of current known issues.
<jgraham> https://
<sadym> have audio issues
<JimEvans> Am only here for a little bit; am boarding a flight in ~20 minutes.
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?
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.
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.
patrickangle: +1. Sending all events will be more predictable then hiding some.
patrickangle: This is also how WebInspector works. If it's not open, it's not collecting logs.
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?
<sadym> IDK
jgraham: See Github issue for other technical details that need clarity.
Update spec to define things in terms of Navigables
<jgraham> github: https://
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?
sadym: Is there a 1:1 mapping between browsing context and document?
jgraham: A frame is a navigable because you can navigate a frame. A browsing context is 1:1 with a window proxy.
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.
<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.
sadym: Could we simply rename current usage of browsing context -> navigable and find a different name for browsing contexts?
jgraham: Yes this should be possible and could help implement this without a breaking change.
jgraham: Let's investigate soon and see if we can do this in a non-breaking way.
sadym: People who have started experimenting with bidi will be impacted by the change.
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.
Editorial meetings
<simonstewart> AutomatedTester: why not just recreate it anyway?
ACTION: AutomatedTester to recreate the editorial meeting invite
Clear log events buffer on document change
<jgraham> GitHub: https://
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.
sadym: This is related to whether logs subscriptions will be based on navigables or browsing contexts/documents in the spec.
jgraham: Deleting the logs is simple to do but does anyone have a use case for keeping the logs around?
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.
jdescottes: No clear reason buffering was implemented the current way. It seemed more straightforward.
simonstewart: If we decide that navigating should flush the buffer, should some other events flush the buffer too?
jgraham: Buffering events from previous pages doesn't make sense for devtools where you care about the current page.
jgraham: With automation, you probably do care about tracking everything.
simonstewart: Do we even need a buffer? Replaying events can lead to inconsistent state on the client.
jgraham: Discussing scenarios for keeping logs.
sadym: Some users may care about logs from beginning of current page but not previous page. Buffer could be useful there.
simonstewart: Should events have an indicator that they are a buffered event and not a "live" event?
jgraham: Having a command to clear the buffer makes sense.
sadym: Subscribing and unsubscribing events should clear the buffer so we may not need a new command.
jgraham: sub/unsub forces all events to be sent over the wire, so won't be as convenient in a high latency situation.
<sadym> based on realm
jdescottes: To reimplement what devtools does, is there a way to know if an event is from the previous page or the live one?
jgraham: You can use the realmId. Documents/navigables could also help if we use those in the spec.
Fix tests failures in Python 3.10+
<jgraham> GitHub: https://
sadym: Can we do something about upgrading websockets library for Python?
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.
patrickangle: Safari is using 3.9 since this is what macOS ships with.
<jgraham> RRSAgent: make minutes