Meeting minutes
RRSAgent: make logs public
RRSAgent: make minutes
User prompts for "beforeunload" event should not automatically be dismissed
GitHub: w3c/
whimboo: This is an older issue. We can't handle beforeunload prompts in webdriver classic. Per spec we always dismiss these prompts during navigation, which makes it impossible to test. In BiDi we have user prompt handling and will implement it soon. Question is what to do with beforeunload handlers. In Firefox we've totally disabled these prompts in WebDriver so it would also affect BiDi. The problem
is that we have to make sure that the prompts end up getting dismissed. We have to allow people to test the prompts. Maybe for classic we should have a capability to set a prompt handler? Or maybe we should handle it differently. Should never block closing a tab.
orkon: In puppeteer whenever you close a page there's an option to decide if unload handlers should run, or if they should be ignored. If they run they are treated like alert dialogs i.e. an event is emitted and the prompt can be dismissed or accepted by the puppeteer user.
whimboo: Does it work when Puppeteer is closing the browser?
jgraham: Three cases. 1) Tab closed. 2) WebDriver initiatted navigation, 3) Other navigation. We've discussed page close, but what about webdriver inititated navigations, do they need an option to suppress a prompt?
sadym: The main problem for the user side is that they want to test what happens with the prompt. Does having an auto-close help with this?
jgraham: Definitely need an event and a way to respond to it. Question is how that interacts with classic webdriver where we just dismiss these prompts automatically so that they don't interefere with navigation. Other question is related to what Alex said where clients might benefit from having a way to ensure that the navigation command will always return without having to listen for the possibility
of a blocking prompt.
sadym: I meant that as a user of BiDi I'd expect the default behaviour to be that if I start a navigation then it completes. If user wants to test the prompts, would it be enough to have a specific command to close the context without suppressing the prompts?
jgraham: I think that might meet the requirements, but it feels a bit strange to suppress the default behaviour except via certian commands / parameters. I think maybe we need a more detailed proposal to discuss?
whimboo: A problem here is what we should do with classic? Do we just want it for BiDi? Could block commands in classic. People wanting to test these prompts might have to use BiDi, so we don't need to change classic.
simons: From Selenium experience, I don't recall people wanting to test this. We do want to be able to refomulate classic on top of BiDi, but that should be possible with events. My favoured position is to leave classic with the existing behaviour and add the new behaviour to BiDi.
jgraham: Are you thinking of classic as "specifically when HTTP kicks off a navigation" or "any sesssion with the HTTP protocol enabled"?
simons: I think it's any time the HTTP protocol is enabled.
simons: If a session has both classic and bidi enabled then it should use the bidi events for the prompt.
simons: For BiDi you'd need to subscribe to the event. Classic would dismiss the prompt. So you'd get a notification that the dialog happened, but it would be automatically dismissed by classic.
patrickangle_: I think it would be unfortunate for the behaviour to be different between a classic command and a bidi command. But it seems like we can't change how classic works when you introduce bidi. I'm not sure how to solve that, but I find it concerning.
Should log.entryAdded events only be sent for Console API calls that use the Printer?
GitHub: w3c/
whimboo: We have log.entryAdded. Right now we always send it even if it doesn't write anything to the log e.g. console.time() which starts a timer. It feels weird that we get an event for this. Maybe only console.timeEnd should get an event, since that actually prints.
whimboo: This would match CDP, I think.
jgraham: I think that CDP has an entire API that reflects the console API so that you could implement everything on the client side. I don't know if we want that here or not.
jdescottes: When we discussed this internally we mentioned two APIs: console.time() twice with two labels, and groupEnd() modify state or produce a warning, so there could be edge cases where things end up writing to the console. Do we want to allow building a console on top of bidi, or just mirroring the output?
orkon: CDP doesn't send messages for console.time() console calls. We found the discrepancy because Firefox was behaving differently to what Puppeteer expects from CDP. On the Chromium side it seems hard to change things here because of devtools.
patrickangle_: Looking at this, it's weird if we only send a message for the second console.time() to tell you there was a problem. In the fututre we might want output to indicate that a timer started. So having some API to provide this information in a structured way including the timer name seems useful.
jgraham: How hard would it be for puppeteer to work around this difference?
orkon: Not hard to work around. But it might be hard for Chrome to send the extra events.
sadym: I haven't looked yet, but does someone know why some commands do and some don't have the Printer call in the console API?
jgraham: console spec is a bit sketchy, but I think that Printer is called for all commands that end up actually writing to the console, and not just affecting internal state.
jgraham: Next step is to figure out if there are implemenation constraints i.e. whether other implementations could be changed to always send events, since that seems more flexible.
Whole-day WG meeting
sadym: Last f2f was quite productive. We suggest having another whole day meeting. Would be online, but also welcome in-person participation. Seems like first week of May might work well given public holidays.
gsnedders: patrickangle_ mentioned that is unlikely to work well for Apple, given other constraints.
patrickangle_: WWDC is confirmed as the first week of June. Trying to carve out a day to join virtually before that is difficult unfortunately.
simons: Travel is also quite difficult right now. London would work better for me.
jgraham: I think it's important to get Apple/WebKit involvement in the meetings; worth delaying for. Might be able to use Mozilla coworking space in London, I'd have to check.
sadym: On our side, there will be some people out from the end of June. Beginning of June should be fine too.
JimEvans: From my perspective, either date would be possible. I want to participate remotely.
patrickangle_: Looking at June, I think the week of June 12th would work well. Remote friendly would be required.
gsnedders: For US participants, starting at 9am CEST isn't ideal. If we do this, how many people will show up in person, or will this be virtual anyway?
jgraham: For a one day meeting I wouldn't want to travel internationally, but others might be more local, or have different preferences.
asck sadym
sadym: Of couse it would be remote friendly. Could have a couple of hubs e.g. Berlin and London. Would it make sense to split into multiple sessions? Would that help with May?
patrickangle_: I thinkk splitting doesn't help with finding time in May.
jgraham: It seems like we've made some progress. sadym can you email the list?
sadym: Sure. I'm still not sure about one 8 hour meeting vs two 4 hour meetings
patrickangle_: Timezone isn't as mcuh of a problem as day.
Extend the roadmap
Github: w3c/
sadym: We're almost finished speccing the items on the existing roadmap. This issue is for prioritising the next list of things that we should add to BiDi, please take a look.
patrickangle_: With some of these it's unclear what the scope is. e.g. what does device emulation encompass. I'd be interesting in seeing the broader goals and the specific use cases that we're trying to acomplish.
sadym: Like e2e scenarios?
patrickangle_: Yes, some of them are very broad areas, so getting more clarity would help.
simons: The obvious things are figuring out the gaps between classic and bidi so we can reformulate classic on top of bidi.
jgraham: Other specs are also extending webdriver classic e.g. HTML, permissions. If we want to e.g. run wpt on top of BiDi we need to figure out a plan to convert those endpoints into bidi.
RRSAgent: make minutes