I recently started poking at bit at improving Selenium-Ruby’s BiDi support, and one thing I noticed is that it can be complicated to determine what context or subscription request an event is relevant to.
The API currently thinks of events as things you turn on/off for various sources, and that you then listen for regardless of source. This works fine in a world where the client is a single, tightly organized entity that knows about all the sources that have been subscribed to, but breaks down a bit when the client consists of independent modules listening for different things from different sources, and even more so when the client is a library (like Selenium) that people might use with various additional plugins or extensions.
Right now, it seems like a client can mostly manage this by doing a lot of book-keeping:
Subscribing to the browsingContext.contextCreated event,
Calling browsingContext.getTree to get the starting situation,
Subscribing to the actual event you are interested in, and
Handling every event by attempting to find the top-level context it is associated with before forwarding it on to the appropriate handlers.
The last step is made more complicated by the fact that there isn’t really a clear rule for where to find an event’s browsing context ID, and in practice different events put it in different places (e.g. the script.message event has it in params.source.context, but the script.realmCreated event has it in params.context).
It would be really useful if events reliably provided the top-level browsing context ID (since these are the only contexts you can subscribe to) they are associated with in a standard place. For example, a base event type might include a params.subscribedBrowsingContext property (which could be optional/null for non-navigable-related script events, like ones coming from service workers).
There might be other good solutions here! Mainly I’d just like to be able to do this with a little less book-keeping, or at least feel confident that the book-keeping steps described above will continue to be workable for future event types.
I recently started poking at bit at improving Selenium-Ruby’s BiDi support, and one thing I noticed is that it can be complicated to determine what context or subscription request an event is relevant to.
The API currently thinks of events as things you turn on/off for various sources, and that you then listen for regardless of source. This works fine in a world where the client is a single, tightly organized entity that knows about all the sources that have been subscribed to, but breaks down a bit when the client consists of independent modules listening for different things from different sources, and even more so when the client is a library (like Selenium) that people might use with various additional plugins or extensions.
Right now, it seems like a client can mostly manage this by doing a lot of book-keeping:
browsingContext.contextCreatedevent,browsingContext.getTreeto get the starting situation,The last step is made more complicated by the fact that there isn’t really a clear rule for where to find an event’s browsing context ID, and in practice different events put it in different places (e.g. the
script.messageevent has it inparams.source.context, but thescript.realmCreatedevent has it inparams.context).It would be really useful if events reliably provided the top-level browsing context ID (since these are the only contexts you can subscribe to) they are associated with in a standard place. For example, a base event type might include a
params.subscribedBrowsingContextproperty (which could be optional/null for non-navigable-relatedscriptevents, like ones coming from service workers).There might be other good solutions here! Mainly I’d just like to be able to do this with a little less book-keeping, or at least feel confident that the book-keeping steps described above will continue to be workable for future event types.