Meeting minutes
<foolip> jgraham: Markdown is easy, right :)
RRSAgent: Stop
RRSAgent: make minutes v2
<foolip> Is incoming audio choppy for anyone else?
<mathiasbynens> audio seems fine here
RRSAgent: create minutes v2
<foolip> Cool, Firefox audio is much better than the native app
<brwalder> @jgraham "brwalder"
RRSAgent: create minutes v2
<AutomatedTester> https://
<foolip> jgraham: spread the word!
Follows from last meeting
<AutomatedTester> jgraham: nothing needs to be mentioned here, all items are later agenda items
Working Group Charter
AutomatedTester: WG is now out of charter
AutomatedTester: We need to recharter. Floated the idea of WG vs CG. Strong opinions in favour of WG.
AutomatedTester: It's on me to take the next steps here; need to reach out to MikeSmith and plh to get the process going.
AutomatedTester: Major deliverables?
AutomatedTester: webdriver-bidi is one
AutomatedTester: Also one more WebDriver/HTTP release, want shadow DOM parts in a spec
foolip: Two deliverables most likely?
AutomatedTester: Yes. Need to check that people are on board with this. Needs AC review. Everyone needs to be in agreement.
jgraham: I agree with that scope
Action: AutomatedTester to send an email to the group to include people not present in the telecon
foolip: Does bidi being a deliverable mean it has to be on the rec track right away
foolip: ?
AutomatedTester: Yes, but timeframe is up for discussion.
AutomatedTester: Currently no staff support, timezone issues. Could work outside the WG structure for a bit, but miss out on the patent policy protection.
AutomatedTester: Our work fits into the living standard with snapshots model, can have rolling time-based deliverables. Need everyone to agree that we're working toward the latest draft not the previous Rec.
AutomatedTester: If you have concerns, please message me. Snapshot model seems close to what we previously did anyway.
Spec status updates
script module https://
log module https://
jgraham: there are currently 2 spec PRs up currently
… they have some feedback and there are a bit rough and are ready for a new set of reviews from everyone
… so please can everyone take a look and comment
foolip: Can you give us a tl;dr?
jgraham: The script module doesnt have script execution yet. It gives you the realms and the events that go with it
… for the log module has 1 type of log event for most things that would appear in the devtools console
… note: it doesnt do performance log events
… and network log events
… and it's the same feature set as in CDP and hopefully same in other protocols
foolip: on the script module, would you need to know the script realm or would you need to know the browser realm
… do they map 1:1?
<brwalder> i think we previously agreed script APIs should accept a browsing context ID
jgraham: I think it does and it makes sense here
… off topic: THere are some "exciting" issues with the browsing context. E.g. how site isolation plays with this
drousso: For items that take more than 1 argument how will this work?
jgraham: the way it is currently described it only takes one and I know that console.log can take a lot of arguments
drousso: in the webkit we have 1 message for [missed type] so would we have an extra message for the error?
jgraham: for the spec we would only want 1 message
drousso: [asks questions about webkit internals and errors]
<drousso> by "internals" i mean logs created by C++ that are still exposed to Web Inspector
jgraham: how internal errors are handled should be sent but it is currently not in the spec.
<drousso> just as a differentiation between the page calling `console.log` and something in C++ calling `Console::log` (or whatever)
jgraham: I think we would need to have more of a conversation about how this works at a later stage
<drousso> ^ +1
<jgraham> jgraham: Later we will add more log types for common things and have a mechanism for UA extension of log types
Handling events the client might miss
https://
github https://
jgraham: one of the problems we have with the current spec is event sending model is
… something happens... we check filters and we send it
… unfortunately this is not what current protocol;s do
… for console logs they create a buffer and when a connection occurs they flush this buffer
… and this difference is problematic
… especially for transitioning clients (e.g. CDP)
… so the implementation of this seems obvious. We figure out what we want to send when clients join
… and I am not suggesting that we need to buffer everything, just events we care about
… In the current model we need to know how to apply filters and then send it
… and we can do it with a [missed algorithm name]
… and we the PR hopefully allows us to do that
… please can people read. If others have a different approach that would be good to hear
shengfa: a question around filtering of top level browsing contexxt, what happens in those sub contexts
jgraham: we would filter everything in the sub contexts based on the filters in the top level browsing contexts
jgraham: this is likely to be next task so please if you can give feedback soon that would ge great
foolip: are you going to be make this fairly general or do it per event we care
jgraham: I think the buffer will be specific to logging and then have general words for other things but not actually have that
… and then have speciifc prose for where we need to reconstruct events
… I am not sure how it will really look like until I write it down
Forward compatibility
https://
foolip: This is an FYI for people to please go read these issues
… I have never done a protocol before mostly webidl but the main thing is that we make sure that things are for things
… but it would be good to make sure that things are forward compatible
… and is CDDL going to be good enough or can we use brwalder work arounds
<jgraham> FWIW I think that's a reasonable soution. It's kind of annoying to have to annotate everything, but I don't see another option
wpt status update
<foolip> Alright, let's go with that unless we hear from anyone else.
jgraham: this is more of a question rather than a topic
… I know there was work on wpt for webdriver bidi last quarter
… foolip is there an update?
<foolip> Tests written so far are https://
foolip: so maksim has been working on this and here is a link
… This prototype is written in nodejs and we have also started looking at the pytest asyncio and await
<shengfa> https://
foolip: we know that there needs to be work on wpt to make it work
… how urgent and how important is this? knowing how quickly people are going to be implement anything
<shengfa> sadym
sadym: I have nothing further to add
shengfa: before the break, I created the RFC for adding a websocket to WPT
… and I have seen that there has been un update to pytest to 4.5
… and after pytest 6 it has dep on asyncio
… I am working on this to do clean up
jgraham: this sounds this great.
… in wpt we hope to drop py2 support within the next month
… the RFC is probably ready to merge as there havent been any comments but I will double check it ASAP
… as for tests are we happy to be sharing tests
<jgraham> RRSAgent: Make minutes v2