w3c / webdriver-bidi

Bidirectional WebDriver protocol for browser automation
https://w3c.github.io/webdriver-bidi/
363 stars 40 forks source link

Support changing timezone for testing #749

Open OrKoN opened 2 months ago

OrKoN commented 2 months ago

Puppeteer allows changing timezone via emulateTimezone for testing how it affects various web and JS APIs.

Seems useful to have it in WebDriver. Related https://stackoverflow.com/questions/44688079/how-do-i-set-a-timezone-in-selenium-chromedriver

Currently, testing this seems to be only possible by changing timezone via CDP or preferences or by changing the system settings.

jgraham commented 2 months ago

Yes, AIUI this is something that multiple clients want.

css-meeting-bot commented 1 week ago

The Browser Testing and Tools Working Group just discussed Emulation-timezone.

The full IRC log of that discussion <AutomatedTester> Topic: Emulation-timezone
<AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/749
<AutomatedTester> scribe+
<AutomatedTester> orkon: This is to raise that we need an API for how to do this. It's part of what people are asking for from selenium and playwright and stackoverflow
<jgraham> q+
<AutomatedTester> ... the current way is to do this via CDP which is very difficult to manager
<AutomatedTester> ack jgraham
<AutomatedTester> jgraham: do we understand the detail that is needed? This is a general question for all emulations APIs
<AutomatedTester> ... do we want to have it manipulating ecmascript
<AutomatedTester> ... if I have misunderstood can we get it corrected?
<AutomatedTester> q?
<AutomatedTester> orkon: we want to affect WebAPIs. I am not sure which ones at the moment
<whimboo> q+
<AutomatedTester> jgraham: I am reading the ecmascript spec and there is a timezone object. DO we want to manipulate that or do we want to manipulate more the browser
<AutomatedTester> ack whimboo
<AutomatedTester> whimboo: in playwright they are doing is manipulating the timezone and set it to the custom time zone
<AutomatedTester> jgraham: I think we need to get a better understanding of what they want to manipulate exactly
<AutomatedTester> q?
<jgraham> q+
<AutomatedTester> ack jgraham
<orkon> q+
<whimboo> this seems to be the place where the TZ env variable gets modified: https://github.com/microsoft/playwright/blob/main/browser_patches/firefox/patches/bootstrap.diff#L503-L510
<AutomatedTester> jgraham: there is no objection from our side? are we happy to have an API that allows us to manipulate the webapis to return a different timezone to the computer?
<AutomatedTester> ack orkon
<AutomatedTester> orkon: from the test and code it manipulates the ecmascript
<AutomatedTester> ... [explains the test from the link above]
<AutomatedTester> q?
<whimboo> q+
<AutomatedTester> orkon: it looks like what they have is a good starting point
<AutomatedTester> ack whimboo
<AutomatedTester> whimboo: they manipulate the TZ env variable in firefox
<AutomatedTester> q?
<AutomatedTester> AutomatedTester: moving forward there is consensus that we will implement this and it will manipulate the ecmascript tz object
<jgraham> q+
<AutomatedTester> gsnedders: looking at the playwright webkit code, I think it would be better that we say that we are emulating this against the top level browsing context so that it does more than what is just in ecmascript
<AutomatedTester> ack jgraham
<orkon> chromium impl https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/timezone/timezone_controller.cc;l=85;drc=f522344e45882da4c7f7cb1b3a0a7bd747d654bb
<AutomatedTester> jgraham: we can write it in a very handwavy way but there should be a minimum list of what it affects
<orkon> q+
<whimboo> q+
<AutomatedTester> ... there is a question around what this would be like for each process... e.g. multiple top level traversable can share a process
<AutomatedTester> ... in firefox this affects the whole browser and it's subprocess since its using the env var
<AutomatedTester> gsnedders: and webkit
<whimboo> q-
<AutomatedTester> ack orkon
<AutomatedTester> orkon: in chrome it is implemented per process... so that could affect multiple navigables/contexts
<AutomatedTester> q?
<AutomatedTester> ... maybe it would be better to have this per user context
<AutomatedTester> ... that might support playwright use cases
<jgraham> q+
<AutomatedTester> ack jgraham
<AutomatedTester> jgraham: not sure if each user context is in a separate process
<whimboo> q+
<AutomatedTester> ... perhaps we need to have a discussion around user context commands
<AutomatedTester> ack whimboo
<whimboo> https://playwright.dev/docs/api/class-browser#browser-new-context
<orkon> q+
<AutomatedTester> whimboo: looking at playwright they are setting it at the process context and we might have a lot of work to do at the user context. Looking at their docs they will wna tit to be at the user context level
<AutomatedTester> ack orkon
<AutomatedTester> orkon: for playwright... they are want it per user context. Puppeteer does this at the top level navigable... which might be good enoug
<AutomatedTester> gsnedders: it all depends on what people want and the implementations might not work at user context
<gsnedders> s/what people want and the implementations might not work at user context/how people are actually using this; developers might not actually run into the differences here because most testing situations only have a single test running at a time, so maybe it doesn't super matter how we define this?/