TLC Meeting - August 13, 2026

Meetings are happening weekly on Thursday at 0700 Pacific / 1000 Eastern / 1500 UK / 1930 India as a video call, and the invite is posted to the #selenium-tlc channel on Selenium Slack. To add items to the agenda for the next meeting, please see our public Rolling Agenda

Participation

Agenda

Meeting Summary

The group discussed the shape of the interaction readiness ADR, closed out the open question on the low-level BiDi ADR, and worked through the remaining points in the network and script and logging ADRs. How browsing contexts, user contexts, and script execution targets are named and scoped came up in both ADRs and will get a record of its own. The Selenium Manager released API ADR was deferred, and the web extensions ADR drew no objections.

Decisions

  • Interaction readiness stays a single preload script with separate exposed entry points rather than separate atoms. AutomatedTester will split the exposed points along stateful versus stateless lines so each call takes only the arguments that apply to it, and will fix the interactability path so it uses the readiness state it currently ignores.
  • The low-level BiDi ADR drops the point where it diverged from jimevans webdriverbidi-net project, so the ADR becomes strict on that item. titusfortner will update the ADR and the Ruby implementation, removing the strict/lax toggle so handling required missing fields is always strict, and will give the group a summary of the implementation once it is done.
  • When a network handler raises, the exception surfaces to the user, no further handlers run, and the event is submitted with the state that was passed into the erroring handler, discarding any mutations that handler made before raising. This decision assumes this matches Playwright behavior. titusfortner believes this matches Playwright and titusfortner will verify and bring it back if it does not match.
  • Event scoping in the script and logging ADR will be expressed as a window handle rather than a context, since events such as console messages attach to a top-level navigable rather than to any browsing context.
  • Browsing contexts, user contexts, and script execution targets get their own ADR, which AutomatedTester will draft.
  • The Selenium Manager released API ADR is deferred to next week after titusfortner updates the PR Body with an improved framing of the options.

Discussion Notes

Interaction readiness ADR

AutomatedTester said he is revising the interaction readiness ADR and will comment disagreeing with splitting it into multiple atoms, since a lot of the internal code is shared and separate atoms would duplicate it. titusfortner’s two objections were the amount of caller-side code needed to execute against the atom, compared with existing atoms that take exactly the arguments they need, and that the interactability path does not use the readiness monitoring at all.

Both wanted one preload. The shape they converged on is the existing get attribute atom: everything is uploaded once in the preload script, and the preload exposes small entry points that take the few arguments each one cares about, so no binding has to write wrapper code for what gets sent. AutomatedTester said he can split the exposed points along what is stateful versus what is stateless in the system, and that he has already fixed some of the interactability gap.

On timeouts, titusfortner noted that other tools default to a 30 second automatic wait and drew a distinction between waiting to locate an element and waiting to act on one: a long wait before acting is reasonable, whereas waiting the full timeout to confirm an element is absent is not always what a user wants. He argued it is more important not to fail than to fail fast, since a slightly slower passing test beats troubleshooting a failure that another few seconds would have avoided. He also observed that a readiness timeout toggle does not depend on BiDi and could be implemented with classic today.

That led to a tangent on mutable capabilities: if capabilities become changeable during a session and the remote end no longer stores all of them, the driver may need somewhere explicit to manage what is mutable versus fixed, and the differing BiDi and classic notions of alert handling will need resolving. AutomatedTester noted this ties back to user contexts and browsing contexts, which is why he has been pushing to settle those first. titusfortner agreed a browsing context ADR might belong in Selenium 5, and said he sees no compelling reason yet to move away from the current intentional switch, act, switch paradigm, though something additional alongside it in the future may make sense.

Selenium Manager download telemetry

titusfortner reported asking the analytics vendor to filter Selenium 4.36 for now, which removes the synthetic monitoring traffic discussed last week. The longer-term problem is cost: the project is riding the limit of what it currently pays for, incidents push it well over, and the vendor’s proposed next tier is a large increase. His plan is to move to a new endpoint with a different approach, and he will bring both a complete plan and a reduced plan so the group can decide what is worth doing.

Two changes drive most of the reduction. Reporting currently runs hourly because it is tied to the cache TTL used for looking versions up, and he sees no reason to report more than daily. Filtering out first runs would drop ephemeral executions. Together he estimated roughly an 80% reduction in volume while keeping the signal needed to make decisions.

Grid slot matching

titusfortner said a user is frustrated with the current Grid slot matching, and that several people have raised issues about it over the years without the project’s approach being cohesive. titusfortner is writing an ADR for the Grid feature so there is something to point to that states how the project approaches slot matching.

Low-level BiDi ADR and Implementations

pujagani reported back on the point left open last week: there is no meaningful way to support missing required inbound fields in Java. Enforcing it would run into null pointer handling and produce either an anti-pattern or an overly complicated mechanism for what is a return type. titusfortner concluded the ADR should drop it, which makes the record match what jimevans has already implemented in webdriverbidi-net and leaves titusfortner, pujagani, and jimevans in agreement. The approach is to be mostly strict everywhere; the generator absorbs much of the per-type work that jimevans has been doing by hand in a static language. AutomatedTester was happy to skip a walkthrough and asked for a summary once it lands.

AutomatedTester had already reviewed and approved the generated Python BiDi layer the week before, which titusfortner had missed. It is entirely additive with nothing wired up to it yet, and titusfortner will merge it rather than keep iterating on unused code. AutomatedTester noted a contributor working on related WebDriver changes needs these decisions settled so the work does not have to be redone, and titusfortner asked that any specific needs be surfaced.

Network async/event API ADR

titusfortner walked through the changes made after last week: intercept by default is now explicit, the URL pattern behavior is clarified so an invalid pattern errors locally and anything valid is passed through, bindings may optionally warn on a suspected glob pattern, and scoping to user and browser contexts was added. He dropped the plan to run examples first and treated any extra warning as an implementation detail; the requirement is that valid patterns are sent on.

An automated review flagged that the ADR does not define what happens when both a browsing context and a user context are provided. AutomatedTester will fix that text; his current reading is that scoping applies to a user context or to a top-level navigable within it rather than to an arbitrary browsing context. titusfortner said this area is still fuzzy for him and AutomatedTester is already working the same problem in another thread.

The remaining change was the uncaught exception behavior described in the decisions above, which replaced text that was not what titusfortner had thought was in the record. With the context piece and the Playwright check resolved, he considered the ADR good to go.

Script and logging async/event API ADR

titusfortner confirmed the agreed direction: execute runs the script with no async variant, promises are wrapped by the script that executes, and pinning is the BiDi add preload script command, so a pinned script becomes available on future navigations rather than immediately. The returned object can be passed to execute to invoke the pinned script, which is what lets an atom such as is displayed be registered once instead of sending tens of kilobytes on every call.

He proposed a generic add event handler method taking a name and a script, where the script defines what it emits and the user acts on it. AutomatedTester questioned how many users would reach for it. titusfortner’s argument is that Selenium would use it internally, with the DOM mutation handler as a specific case built on the generic mechanism while keeping its own dedicated method, and that framework and client library authors could build their own without Selenium having to wrap everything a user might want. He was unsure whether the object such a handler yields is one Selenium controls and shapes, as it does for an intercepted request coming off the socket, and will run examples to check before the ADR claims shaped payloads there. He also noted that, unlike the network handlers, an uncaught exception here is logged rather than raised, since these handlers observe rather than intercept an action under test and the logged output may not be well formed.

The context scoping wording drew the longest discussion. AutomatedTester said the examples are right but the wording is wrong: execute can target an iframe, a web worker, or a service worker, whereas events attach to a top-level navigable, which is a tab. He suggested calling the execute target a realm, matching the specification’s language about executing script in different realms. p0deje said the concept makes sense but was puzzled by the name and thought realm would confuse people, since users know windows and tabs; pujagani shared that concern. titusfortner noted context has the same problem, and proposed handle for the event scoping and realm for the execute target, with the types making the distinction clear where the language allows it; window handles are plain strings in at least some bindings, which limits how much typing helps.

p0deje suggested not trying to settle the whole naming question now and instead getting an ADR out focused on how user contexts relate to the driver and how switching tabs works, with execute defaulting to the current context. pujagani added that whatever is chosen needs to be used consistently across the Selenium conversation so each term means one thing, and said AutomatedTester should take the ADR given his understanding of workers and realms. titusfortner agreed, said he does not expect to make much progress on the script ADR next week, and will do the basic refresh from this discussion.

Selenium Manager released API ADR

titusfortner wanted diemol present and said he needs to reframe the record, because he and diemol appear to have different ideas about what would be required to release Selenium Manager independently. AutomatedTester pushed to move ahead, citing his documentation PR removing the beta label from the Selenium Manager title: in his testing across several LLMs, anything marked beta gets avoided, and he did not want perfect to be the enemy of good.

titusfortner’s concern is that things have been added to Selenium Manager over time knowing it is tied to the Selenium version it ships with, and that the current defaults are not necessarily the ones the project wants; once it is out of beta, the API that is there is the API you are stuck with. He also noted that releasing it independently means losing control over which versions are used where, and that the original intent was an opt-in backup that only executes when the test would otherwise fail, which has drifted over the years. What he wants is to walk through the settings and defaults and confirm each one, and the group agreed to cover it explicitly next week.

Web extensions ADR

titusfortner presented the web extensions ADR as less controversial than expected: the driver gets install and uninstall web extension methods, and the existing Firefox install add-on method moves over to them. The earlier blockers no longer apply, since Chrome dropped the extra arguments it once required and geckodriver now supports the new BiDi functionality, so there is no difference in the vendor arguments Firefox accepts. A reviewer asked for web extension rather than extension in the name, which titusfortner agreed reads better given Java uses install extension name while other bindings use install add-on name. Firefox on classic keeps the classic behavior, and the BiDi path supports both Chrome and Firefox. No objections were raised to the three decisions in the record.

The known gap is that Chrome accepts only a path, not base64, so extensions cannot be installed through the Grid. p0deje asked whether the file upload mechanism could be reused. titusfortner noted the upload endpoint takes a file rather than a directory, so an archive might work while a directory would not; p0deje pointed out Ruby can already zip a directory client side, so part of this could be worked around in the bindings. titusfortner was comfortable leaving Grid support not working for now and will check what the remote end actually does, since that piece is Grid code the project controls rather than anything the browsers have to implement.

Separately, titusfortner described a W3C discussion in WebDriver BiDi about extensibility, prompted by this ADR: Firefox defines some vendor specific commands within the specification, and it is not settled whether the generators should pull those in through a merged CDDL with an extension point or reference them independently.

Action Items

Last modified August 14, 2026: Add TLC meeting minutes for August 13, 2026 (30e0f540494)