Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for "userContexts" argument to "browsingContext.setViewport" command. #876

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

lutien
Copy link
Contributor

@lutien lutien commented Feb 11, 2025

A proposal to add "userContexts" argument to "browsingContext.setViewport" command.

Closes #851


Preview | Diff

index.bs Outdated

<div algorithm="set viewport when a top-level traversable is created">

When the [=set up a window environment settings object=]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably a wrong place to hook on, but since WebDriver BiDi navigable created should happen when everything is set up, and likely we have to set up viewport even before preload scripts run we need something else here, and will have to add something to html spec. So this is more of placeholder for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually need to do this once per document, or only really once per navigable? It seems like ideally we run this once per top-level traversable, since we seem to skip over everything else, and then you can assert that the input navigable is a top-level traversable, and skip a bunch of checks below.

I think for now it would be better to have a sketch of under what conditions we want to run these steps (maybe "after creating a document in a new top-level traversable, before running the 'Run WebDriver BiDi preload scripts' steps") rather than being more specific in a way that's misleading.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds good to me, it's basically what I wanted to specify, but didn't know how :)
Updated ✅

@lutien lutien force-pushed the add-user-contexts-to-set-viewport branch from c607300 to 751867e Compare February 11, 2025 15:28
@lutien lutien marked this pull request as ready for review February 11, 2025 15:49
@lutien lutien requested a review from jgraham February 11, 2025 15:49
index.bs Outdated
@@ -2966,6 +2966,13 @@ between [=navigables=] and device pixel ratio overrides. It is initially empty.
Note: this map is not cleared when the final session ends i.e. device pixel
ratio overrides outlive any WebDriver session.

A [=remote end=] has a <dfn>viewport overrides map</dfn> which is a weak map
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might make all the structs named rather than use anonymous ones i.e. something like

A <dfn for="viewport-configuration">viewport dimensions</dfn> is a [=struct=] with an [=struct/item=] named <dfn for="viewport-configuration">height</dfn> which is an integer and a [=struct/item=] named <dfn for="viewport-dimensions">width</dfn> which is an integer.

A <dfn>viewport configuration</dfn> is a [=struct=] with an [=struct/item=] named <dfn for="viewport-configuration">viewport</dfn> which is a [=viewport-configuration/viewport dimensions=] or null and an [=struct/item=] named <dfn for="viewport-configuration">devicePixelRatio</dfn> which is a float or null.

A [=remote end=] ahs a <dfn>viewport overrides map</dfn> which is a weak map between [=user contexts=] and [=viewport configuration=].

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, that's look nicer, updated

<div algorithm>
To <dfn>set device pixel ratio override</dfn> given |navigable| and |device pixel ratio|:

1. Let |navigable| be the [=/navigable=] whose [=navigable/active document=] is
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a case where this isn't a no-op?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess now it should be handled in the command algorithm?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to me it read as Let |navigable| be |navigable|

index.bs Outdated

<div algorithm="set viewport when a top-level traversable is created">

When the [=set up a window environment settings object=]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually need to do this once per document, or only really once per navigable? It seems like ideally we run this once per top-level traversable, since we seem to skip over everything else, and then you can assert that the input navigable is a top-level traversable, and skip a bunch of checks below.

I think for now it would be better to have a sketch of under what conditions we want to run these steps (maybe "after creating a document in a new top-level traversable, before running the 'Run WebDriver BiDi preload scripts' steps") rather than being more specific in a way that's misleading.

index.bs Outdated
viewport=] to be the <code>width</code> of |viewport| in CSS pixels and
set the height of the |navigable|'s [=layout viewport=] to be the
<code>height</code> of |viewport| in CSS pixels.
1. If the implementation is unable to adjust the |navigable|'s [=layout viewport=]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have this here; what happens if it fails when we try to adjust it in the user context case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's a good question. I guess the implementation should know if they are able to adjust the layout to the requested settings without relation to the specific navigable. I moved this check outside and remove mention of the navigable. Let me know what do you think.


1. For the |navigable| and all [=descendant navigables=]:
1. If |user context| is null, return [=error=] with [=error code=] [=no such user context=].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This failure inside the loop means that we'd partially apply the command to any user contexts before the one that doesn't exist; we should probably fail if any don't exist.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, made the validation loop first.

@lutien lutien force-pushed the add-user-contexts-to-set-viewport branch from e9f1941 to 1259908 Compare February 18, 2025 11:33
@lutien lutien force-pushed the add-user-contexts-to-set-viewport branch from 1259908 to 404847d Compare February 18, 2025 12:00
@lutien
Copy link
Contributor Author

lutien commented Feb 18, 2025

The build fails, but it doesn't look that it comes from my changes. Locally, I can reproduce it on main branch as well.

@lutien
Copy link
Contributor Author

lutien commented Feb 18, 2025

Alright, I figured out what is wrong: speced/bikeshed-boilerplate#135.

@lutien lutien closed this Feb 18, 2025
@lutien lutien reopened this Feb 18, 2025
@lutien lutien requested a review from jgraham February 18, 2025 18:12
Comment on lines +4738 to +4740
1. If |command parameters| [=map/contains=] "<code>userContexts</code>"
and |command parameters| [=map/contains=] "<code>context</code>",
return [=error=] with [=error code=] [=invalid argument=].
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably also raise an error if both parameters are missing? It will effectively be a noop and won't crash or anything, but the user should know about it. Otherwise they might assume it just applied setViewport to all navigables?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's true, added ✅

index.bs Outdated

1. [=Set viewport=] with |navigable| and |viewport|.

1. Run the [[cssom-view-1#resizing-viewports]] steps.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(not related to your PR, but those steps seem to require a document to run against?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, looks like it, updated ✅


1. If [=viewport overrides map=] [=map/contains=] |user context|:

1. If |viewport overrides map|[|user context|] [=map/contains=] the <code>viewport</code> field:
Copy link
Contributor

@OrKoN OrKoN Feb 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be [=viewport overrides map=] (here and below)


1. If [=viewport overrides map=] [=map/contains=] |user context|:

1. If |viewport overrides map|[|user context|] [=map/contains=] the <code>viewport</code> field:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think [=map/contains=] cannot be used here since |viewport overrides map|[|user context|] is a struct

@@ -4648,71 +4659,154 @@ The <dfn export for=commands>browsingContext.setViewport</dfn> command modifies
</dd>
</dl>

<div algorithm="remote end steps for browsingContext.setViewport">
<div algorithm>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this helper algorithms could be moved outside of the command section so that remote end steps follow the CDDL type definitions for the command.

viewport=] to be the <code>width</code> of |viewport| in CSS pixels and
set the height of the |navigable|'s [=layout viewport=] to be the
<code>height</code> of |viewport| in CSS pixels.
1. If the <code>context</code> field of |command parameters| is present:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could use [=map/contains=] instead of "is present"


1. Otherwise:
1. [=map/Set=] [=viewport overrides map=][|user context|] to a new [=/map=].
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't [=viewport overrides map=][|user context|] defined as a struct?

1. Set |viewport overrides map|[|user context|]["<code>devicePixelRatio</code>"]
to |command parameters|["<code>devicePixelRatio</code>"].

1. [=list/For each=] |top-level traversable| in the list of all [=/top-level traversables=]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
1. [=list/For each=] |top-level traversable| in the list of all [=/top-level traversables=]
1. [=list/For each=] |top-level traversable| of the list of all [=/top-level traversables=]

I think the infra standard recommends for each |item| of |list|.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for "userContexts" argument to "browsingContext.setViewport" command
4 participants