Meeting minutes
RRSAgent: quiet
RRSAgent: silence
<jgraham> RRSAgent: make minutes v2
<jgraham> RRSAgent: make minutes public
<jgraham> RRSAgent: make logs public
<jgraham> gsnedders: Might depend on which browser?
<gsnedders> jgraham: I've tried three
<jgraham> (or only be enabled for some corp. installs I suppose)
<gsnedders> https://support.zoom.us/hc/en-us/articles/115005666383-Show-a-Join-from-your-browser-Link
gsnedders: maybe for the next meeting? unless you can m
I can't figure it out from the things now
<simonstewart> I think you can wait for a Long Time, and then zoom asks if you want to join via the browser
gsnedders: try https://browserstack.zoom.us/j/93785219642?pwd=QUZ1dkZyQUJUMnpvVGFwVFI2RXVZUT09 and see if that works
Followups from previous meeting
jgraham: I can't talk about followups but what we have done since the last meeting. bwalderman has landed a PR on how to create commands
… We have used a schema language that is based off a spec that looks like it should work
<jgraham> CDDL
Non-upgrade sessions
jgraham: As part of the initial landing of the first command we had some fall out.
… there is no way to send commands unless you have a session but in the httpversion yuou can do it at any point
… so the question for this group is : Do we start from the stance that we upgrade from the start or do we have a status command?
ack
simonstewart: the status command isn't just used by the things that already has a session. It's used as a health check
… we have things set up in the http version to start from a well known http endpoint ånd fan out. Why cant we do that with the wss connection?
bwalderman: the status command is there to show ghow to do CDDL
… I was wondering how we should approach duplicate commands between the 2 specs?
… as sessions without an upgrade would be useful. we just havent spoken about it before
jgraham: in response to simonstewart is that you get a url from the http session. Do we think we should support an wss from the start?
… status is more like a placeholder so this made me think about the session.
gsnedders: we should not spend too much time here and can loop back to it later
… I can see situations where we don't want to start the browser with a window but have a session and that can be really useful
<jgraham> I agree with gsnedders fwiw
simonstewart: to bwalderman point on duplicate commands, I think people willuse one or other, so it seems reasonable to duplicate for now. eventually we wiull go to full bidi
… I can see having a proper defined wss url being useful in the future but we should worry about it for now
… end of message
bwalderman: that makes sense... we will want to get to the point of removing duplications . I think we will need to come a point where interleaving commands becomes super important
simonstewart: we could habve a predefined webdriver domain that goes over the bidi and that we can call out to the origianl spec and that makes life easier
jgraham there has been a requirement form the start to support http and bidi.
Console log interoperability
maja_zf: I filed an issue about a logging module in the spec.
… since this would be a good avenue for prototyping
<simonstewart> Can we get a link to the logging module, please?
https://github.com/w3c/webdriver-bidi/issues/45
maja_zf: we are seeing testers want this feature and there can be interop issues
simonstewart: logging is something that people really want and there are ideas we need to do it
… this seems like a reasonable start
brrian: this seems to be oriented towards console.log but there are other logs that are useful
… there is logging that doesnt come from the engine but is useful in the client
… [give iOS example]
<simonstewart> Side note: The equivalent API in Selenium looks like this: https://github.com/SeleniumHQ/selenium/blob/trunk/java/client/src/org/openqa/selenium/logging/LogEntry.java
<simonstewart> (Essentially a level, timestamp and message)
jgraham: A "bad" way to interpret it is what would be in the console in devbtools .
… so it's not just console but things that come from the engine
… should we just say send all from the protocol and let the client filter
… should we be filtering in the browser instead of the client
<brrian> in WebKit at least, console messages in DevTools can come from the engine, or appended by the embedder. Blocking valid navigations that would launch another app is a WebDriver-specific behavior and so is not currently logged to console. It may be that logging to console is the easiest way to exfiltrate the event to WebDriver BiDi.
bwalderman: I would try limit what can go itno the logging to a console and if you want platform events you would subscribe to those logging events
and they would be differently shaped instead of shoehorning it all into 1 type
maja_zf: filtering on the browser makes a lot of sense
… and we don't want that network pressure on the cleint
bwalderman: filtering is still a good idea. What granularity do we want to subscribe to
… what is less clear. Do we want to filter at the level of just 1 target with z`console.error`? If yes, that's going to be interesting to setup
simonstewart: One of the things that hasn't been covered as before. We had the ability to get logs from intermediary nodes and that is useful
<maja_zf> Intermediary node in what sense?
<jgraham> maja_zf: Middleware between the browser and the client
<simonstewart> https://www.w3.org/TR/webdriver/#dfn-intermediary-nodes
simonstewart: we should look at previous discussions to make sure we arent missing things
q>
<gsnedders> jgraham: "not to spend time on this but…"
jgraham: as a consideration we should think about logging on intermediary nodes different to the bidfi work
maja_zf: my other question is... there are not enough of the prerequistes to get this done. Is this discussion too premature?
<simonstewart> maja_zf: I've found some previous minutes about logging: https://www.w3.org/2017/11/10-webdriver-minutes.html#item01
jgraham: We don't have enough infrqa in the spec yet
<simonstewart> And previous discussion: https://www.w3.org/2013/06/13-testing-minutes.html#item02
jgraham: and once we decide what is next and then we can go from there.
Sync on next work items
jgraham: Are there specific plans to work on over the next month. I am going to start looking at browsing context and realms
bwalderman: I won't be able to do much over hte next few weeks due to other commitments
RRSAgent: make minutes
RRSAgent: make minutes v2
<simonstewart> BTW, who here is also on the W3C Slack?
RRSAgent: publish minutes
RRSAgent: publish minutes v2