Closed OrKoN closed 1 year ago
cc @jgraham @whimboo
I suggest we make this an option (and maybe don't even have a default, just require it). Something like activate: bool
in the definition of thebrowsingContext.create
command.
Although again, you need to think through what happens in the case that you create a context in a window that doesn't have system focus (e.g. one that's minimized). Are you expecting the window to be unminimized if you create an active context, or are you expecting that it will become the active tab if the window is separately unminimized?
I would expect this to match the user-observed behaviour by default: if the user clicks File > new Window, the window is maximized (if it was minimized) and brought to the front (I tested and that is the behaviour in Chrome and Firefox on MacOS.). As far as I know, the only case when the context is created in the background by the user is the Cmd + Click on links. Perhaps, if it is configurable in the browsers, it would make sense to use the default browser behaviour and allow changing it via capabilities/profile folders or the parameter on the create command.
What is the motivation for creating the contexts in background by default?
"Matches the user-observed behaviour" is really hard to define. For example the default user-observed behaviour of "open link in new tab" on desktop and mobile Firefox is to open it in a background tab. On the other hand opening in a new window (on desktop) does focus the window in the default configuration, similar to opening a new blank tab.
But all of these things are subject to change, and WebDriver allows possibilities that aren't open to users (e.g. opening a new tab in a minimised window on non-mac platforms), plus, if the behaviour is observable, being consistent between browsers is more important than being like the UI.
WebDriver classic tried to avoid this problem by claiming that browsers under automation should act as if OS-level focus wasn't important. That doesn't quite work for BiDi, so instead we need to allow authors to get consistent, defined behaviour, whilst also not restricting what they can do. In that case having a flag in the API, and precisely defining what happens with each value, seems like the way forward.
and maybe don't even have a default, just require it
This is a breaking change, absolutely everywhere. Most WPT and local tests will break, all at once. Let's start with adding a default and then we can bikeshed whether to make it explicitly set by the user or not at some other point.
Fixing wpt tests would probably be a one line change, since they could provide some default. But sure, I'm also happy with a boolean flag activate
whose default is false
(since we decided that boolean flags should always default to false, and it makes sense that the default behaviour is to do the minimal thing, which would be to not adjust the focus).
"Matches the user-observed behaviour" is really hard to define. For example the default user-observed behaviour of "open link in new tab" on desktop and mobile Firefox is to open it in a background tab. On the other hand opening in a new window (on desktop) does focus the window in the default configuration, similar to opening a new blank tab.
I agree but also I want to point out that there might be (rare) test scenarios when the clients wants to test how the app works with such browser-specific behaviours (since there are differences in behaviour between background and foreground contexts). Perhaps, the default value should be "do whatever the browser normally does" (hard to define though) plus activate=true|false
. Also, I don't view the "open link in new tab" as a complete equivalent to browsingContext.create
(the browsingContext.create
does not accept a URL, for example) but rather as an equivalent of the "new tab/window" action. Another alternative, perhaps, could be a parameter for browsingContext.create
called background
with the default value false
.
Another aspect to discuss is whether creating a context with activate=true
would be equivalent to creating the context in the background and calling browserContext.activate
right after. If there is no practical difference and we don't want to change the default value, then we could just expect the client to activate the context.
Unfortunately "do whatever the browser normally does" is an interop nightmare, and for WebDriver[-BiDi] in particular the likely consequence is that tests can't be ported easily between different browsers. So I think we need to specify a default here.
I believe that activate=true
would most likely be the equivalent of just calling activate
immediately after creating the tab. So yes, I think the minimal spec change here would be to enforce the behaviour that the tab is not activated when just calling browsingContext.create
, and allow clients to call activate
manually if that's what they want. This could be optimised in the future if we find that it's a common use case.
This could be optimised in the future if we find that it's a common use case.
Puppeteer creates all new contexts in the foreground by default so we will need to call it every time. Also, Puppeteer does not even provide an option to create contexts in the background and we have not received user requests about that so far. I wonder if other tools need the background creation.
The Browser Testing and Tools Working Group just discussed Update browsingContext.create to require the new context to active (in the foreground)
.
Currently, Firefox implementation creates contexts in the background and Chrome implementation in the foreground. From the user perspective, I believe it makes sense that the new window/tab is focused and in the foreground just like when the user opens a tab manually. Plus it will help avoid a bunch of surprises due to throttling.
browsingContext.activate
would help with that but strictly speaking is not related to this issue as the foreground creation should be the default.Related bugs: