Meeting minutes
Define behavior of browsingContext.navigate for javascript: URLs
<jgraham> github: w3c/
Henrik: Trying to make our implementation more secure. Question came up about handling javascript: URLs.
… If we have an about page open in the parent process, we don't want if we need to wait or not. That leads to undefined behavior.
… We don't know at least for classic how many users use javascript: URLs.
… I'm wondering whether we can drop support for javascript: URLs.
… If someone's using them, that would then report an invalid argument error.
… I can create a PR. Navigation with javascript: URLs would still possible through navigation within a page. It's really only about the "navigate" command.
Update for "make userContext mandatory in event payloads"?
Henrik: I'll start with BiDi. If that does not cause any problem, we can adapt it to Classic afterwards as well.
<jgraham> github: https://
Henrik: The question is mainly about landing the PR. We are only waiting for Chrome to keep up. When can userContext be added to event so that we can make it optional instead of mandatory?
Maksim: A question of prioritization.
… Should not be a big deal.
Do not allow for forcing classic scrollbars
<jgraham> github: w3c/
Maksim: Don't remember if we already discussed it.
<whimboo> w3c/
Maksim: Apparently, it's not possible for us to force the classic scrollbar for all devices, e.g., for Android where it will be overlay.
… For platform where classic scrollbars are shown, the change would change them to overlay or the other option.
jgraham: Reading the comment from Sam, it seems reasonable. The pattern that we use in cases where stuff is not supported everywhere is to report an error. Client has to deal with that.
Maksim: I don't know if, from WPT perspective, it would help if we fail with an error. That would make some tests fail. Not sure that's the right approach.
jgraham: Two cases we care about: 1) You're a desktop platform and you cannot have scrollbars, a number of tests will fail due to reftests. In that case, it would be good to know that this is the reason why the tests are failing.
… 2) Mobile use cases where classic scrollbars aren't usually supported. Making tests not designed for mobile run under mobile is work in any case.
… I also don't think that WPT is the main driving case here. In general, I don't think it's possible to design the API such that everything works on every platform. I'm not sure that's a special enough case that we should do something specific for that.
… I'm also happy with a default option here.
… But I do think to request a specific configuration even though it may not make sense in some specific environment.
Maksim: Then that means we don't want any emulation. It's different from the default one: let's say we have a global emulation overlay. Null and default become different.
… From the user perspective, we're leaning on option 3 in the proposal, extending the options with default.
jgraham: I think that would be fine.
Allow for specifying schema in "proxy"
<jgraham> github: w3c/
Maksim: Call for action, but I see that Henrik already provided comments. I'll revisit the PR.
Henrik: 2 or 3 PRs opened.
… Would be good to know which one we pursue.
Maksim: #1922 should be the one. The others are draft.
Streaming API
<jgraham> github: w3c/
sasha: Where we ended is that Alex pushed back on adding the option to return stream from script evaluation.
… If we would be ok to removing it, we would need to figure out the return type evaluation, but not adding support for network body for now and move forward with the rest.
Maksim: From I understand, we try to get with the API. The JS case is quite specific case. For screencast and network body, it's a completely different problem.
… Alex' point is that it would make more sense to create explicit features for them for scenarios where we're explicitly going to use them.
jgraham: I think it's ok to merge the API without connecting with anything at the moment.
… Network bodies and screencast are slightly different things. I think there is a little bit of an advantage with a design that is more generic.
… I also agree that it's not the most compelling use case.
… It's strange if you have to access a stream from different APIs.
sasha: I have the feeling that for each specific use case, we'll need to handle it separately. Additional wiring may be needed for each use case.
… I would like to make progress while we figure this out.
Maksim: I don't think there is any user benefit but there is a slight benefit for those that will provide the streaming of the screencasting. Meaning it's useful for us, writers of the specification, not the end users.
jgraham: I think the current proposal is to remove the connection to the js stuff for now. And land an API that isn't connected to anything.
Maksim: Either that way, or postpone it to the API in the network stream use case.
jimevans: Doesn't defering until we land on the other use cases take us back to the initial problem in terms of using platform primitives? Or is that completely orthogonal to where we are here?
jgraham: I'm not completely sure I understand. The advantage of landing the API is that with the shape in place, we're not blocked on what the API for streaming is going to look like.
… I'm not sure about platform primitives. There are different mechanisms. But the high-level API feels like we have some level of agreement for WebDriver.
jimevans: We had different PRs around that feature already in terms of defining streams, stream access. One of the sticking points I recall is that we need some kind of realm for the stream to live in.
… And that's what I'm referring to.
… If we want to shape the API first and define the implementation later, I'm fine, but I don't want to block ourselves in progress because we haven't figured out all the internal workings of how the API should work.
jgraham: That makes sense. That is still the case.
… We would just take out the part that gives you access to the stream.
… It is true that it isn't entirely clear how some of the streams will work as they need to be in a realm. For example with screencasting. Do we use a virtual realm? Etc.
… With some streams, the realm is more defined. E.g., with fetch.
… I like the part where you said: "we should do this"
Pass a "hasImmediateNavigation" flag to the "browsingContext.contextCreated" event.
<jgraham> github: w3c/
sasha: New flag to indicate whether this a navigation soon.
… What I propose to do with lazy iframes is to set the flag if certain conditions are met.
… Then we had a discussion that maybe we don't want to handle it altogether, maybe for lazy iframes we want a separate flag to say it's a lazy iframe and whether it is in the viewport.
… And the flag that we introduce now is only going to cover cases except lazy iframes.
… And later on, for lazy iframes, we introduce more flags.
jgraham: Two main use case: Should I be waiting for the load even in this frame? Should I be running a preload script in this frame?
… One other considerations is: do we want a bunch of boolean flags here? Or is more like an enum-shaped?
… Sometimes, browsers have background contexts, extension pages. At the moment, we're not exposing those.
… We should not be too specific.
Maksim: The only difference is that, what we want to say is that the navigation will start even though we don't know when it may end.
… We may try with different approaches, and figure out lazy later on.
sasha: For the lazy iframes, proposal is to only set the flag when navigation is going to be happen when it's added to the viewport.
… Figuring out whether we want to handle lazy iframes or not.
… If check whether src attribute is set.
… We may need a better name for that property. What do we want to say with this property in terms of navigation?
Maksim: I don't think it's any different from iframes which are navigated by JavaScript.
… From that perspective, I agree with that proposal, we only have to show that the navigation already started.
Periodic screenshots
<jgraham> github: w3c/
sasha: Idea would be to bring an API similar to CDP when clients can ask for a screenshot when the screen changes.
… Command to acknowledge that the screenshot was handled.
… Agentic tools may want to see what is happening in the page.
… I'm concerned with the shape of the API. We don't have other cases where we would call a command to setup an event.
… And another command to maybe acknowledge it.
… Alternative proposal would be to have a streaming API here.
… Command would configure this screenshoting, and client would pull the stream. We would have the backpressure handled in that scenario.
… Client can call it as soon as they're ready to receive the next one.
… I just wanted to start the discussion today.
jgraham: One thing I just thought of is that the stream command is presumably blocking, while waiting for an event is not.
… You need a thread vs. an event loop. Maybe that's a meaningful difference for clients as well.
Maksim: It looks like this case would be better handled with events and doesn't need streaming at all. I haven't checked in details yet.
jgraham: Let's discuss in the issue.
WG rechartering - ongoing call for review and upcoming change of staff contact
tidoust: The WG was temporarily out of charter. Apologies. There is a new proposed charter being reviewed by the AC. Some already replied, but not all. Please support! Then we can adopt it. Practically speaking we have a tacit rule that we need 5% of members to express support before it gets rechartered. IF there aren't enough votes we need to
justify it.
tidoust: Note that the proposed charter doesn't have me as staff contact. I will hand over to Xiaoqian
TPAC vs October meeting
<tidoust> Maksim: I assume that we still want to have an October meeting on top of TPAC?
<tidoust> jgraham: I would encourage people to attend TPAC. 2 days of meetings.
<tidoust> ... I would cancel the other October meeting.
<jimevans> (I'm registered for remote TPAC participation)
<tidoust> Maksim: Works for me.