Meeting minutes
<jgraham> RRSAgent make minutes
Handling of "display:contents" elements as origin
github: w3c/
henrik: We talked about display:none in the last meeting. Follow-up action is with display: contents. At the moment, they don't have a bounding box, so we raise an error, not clickable.
… It looks like we have a way to get the bounding box rect for these elements but through a range.
… I have sketched this. Check the issue and example in last comment.
… The example page has display: none, then button, then a paragraph with wrapping. All of these look fine. I checked with Chrome, Firefox and Safari.
… If we agree with the approach, I should be able to prepare a PR to update the spec.
<jimevans> ack
sadym: I haven't checked yet. I will take a look and comment on the issue.
Henrik: OK. Other concerns?
[none heard]
Henrik: Will wait for comments then.
ACTION: Henrik to get further feedback from Apple
Add an option to the "browsing.setViewport" command to define a type of scrollbar shown
github: w3c/
Henrik: About scrollbards. I noticed that we have different behavior for screenshots.
… I saw that scrollbars are disabled in Firefox. In BiDi, we don't disable the scrollbars for now.
… On Mac, there are no overlay scrollbars and this is causing problems.
… The question is whether we want to have an option to specify whether scrollbars should be displayed, static, overlay.
… I'm not sure whether scrollbar width and height are different between browsers.
… It would be great to have an option to enable them.
jgraham: My only concern with this is that maybe we can force overlay scrollbars, but it's not clear to me that we can force non-overlay scrollbars across platforms. Which would lead to non-consistent behavior.
… Not necessarily blocking, but maybe a bit surprising if option values do not work consistently across platforms.
Henrik: It may be good for browser vendors to check how things work across platforms and report.
sadym: Do we have use cases of forcing the scrollbar to be shown?
… I can imagine that the issue is when the scrollbar is shown, as it changes the dimensions. If we allow to hide completely, wouldn't that cover all use cases?
jgraham: You might want to test with both on platforms that accept both shown and overlay scrollbars. That seems a reasonable use case.
… Maybe my concern does not matter.
… If there's no concept of visible scrollbars at all, perhaps that's fine.
Henrik: For Playwright, they disable them completely. Checking on all platforms would be good.
ACTION: Henrik to check whether scrollbars can be disabled across platforms.
Extend `browser.createUserContext` with `unhandledPromptBehavior` parameter
github: w3c/
sadym: After the first extension to createUserContext, I have a couple of new proposals which are PRs.
… For unhandledPromptBehavior, two approaches are possible. Time to discuss and make a decision!
jgraham: I agree that we shouldn't do more with capabilities here.
… When we create a user context, at that point, you can specify unhandledPromptBehavior for the entire context, which is more fine-grained than what we have today, but less fine-grained than per browsing context.
… It's not clear to me what the objection to this PR is. It seems fine. Later on, if we want to do it per browsing context, we can. For now, per user context seems a nice start to address use cases we know about without adding too much complexity.
jimevans: Seems that we can get to consensus on this one!
[no objection heard]
Extend `browser.createUserContext` with `proxy` parameter
github: w3c/
<whimboo> RRSAgent make minutes
sadym: Call for action to take a look and provide feedback. I don't think it's controversial.
… It was reviewed by Alex from our team. We'd like approval from at least one other vendor.
Support retrieval of content quads for elements with CSS transformations
github: w3c/
jimevans: Stemming from some of the work that Playwright is doing, I believe
sadym: Elements can have some CSS transformations. A rectangle can become non rectangle and there are scenarios where you want the geometry.
… There's a pending proposal under discussion in the CSS WG, which could end in a DOM API.
… However, that can take some time.
… The second approach is to take the hook from the CSS PR and add them to BiDi and provide the endpoint in BiDi without waiting for the DOM API to do that.
jgraham: If the definition of this is in CSS, to me that solves the biggest objection here. In principle, I prefer the idea of requiring people to use a DOM API here
… but we could have an endpoint in BiDi that does the same thing that ends up being a wrapper to the DOM API.
… We should assess whether the DOM API is coming soon. If not, we may want to go through the fast pass here.
whimboo: From our side, it would be ok as that shouldn't change much in the implementation.
sadym: It's implemented in CDP, for sure.
… I don't think it's exposed in DOM API but I haven't checked.
… If we go with a BiDi approach, we should consider deprecating it after once the DOM API is available everywhere.
jgraham: I also think that the first thing we need to do is assess the status of this proposal. PR is one year old. That is very much the blocker at this point.
jimevans: Could someone reach out to the CSS WG?
sadym: I can do it.
jgraham: We can find someone at Mozilla as well.
Julian: emilio is tagged on the issue.
<jgraham> RRSAgent: make minutes
ACTION: sadym to check status of the issue in the CSS WG
Access downloaded file content
github: w3c/
<jgraham> RRSAgent: make logs public
sadym: I started drafting a PR, which requires some HTML spec refactoring. I'm not sure how to proceed with that.
… The whole download process in HTML is non normative, that's the problem.
… "If the file download is canceled by the user or the user agent, do something".
jgraham: Lots of the old bits of HTML are still like that. It's up to HTML spec editors to accept the PR. From our point of view, as long as it's basically calling the right bits and everyone knows what it triggers, I think that's fine.
sadym: If we go that way, we have to land in BiDi spec with the hooks and get feedback from HTML people afterwards. We cannot do the other way round.
jgraham: Yes, that's annoying but there's no easy way around that.
sadym: Then a call for action to review the PR so that we may land that in BiDi.
WPT: align webdriver/tests/interop/beforeunload_prompt.py with spec
github: web-platform-tests/
sadym: Heads-up that we misinterpreted the specification. Currently we are slightly misaligned with Firefox, and work is in progress to align back.
Progress towards publishing a Candidate Recommendation Snapshot
github: w3c/
<jgraham> RRSAgent: make minutes