1716541 - Implement Emulation.setTimezoneOverride

Status: NEW

(Remote Protocol :: CDP, enhancement, P3)

Description

[brnbs]

This command is missing from the list of supported/planned CDP commands.

Based on the Playwright implementation this feature can be implemented on all platforms by changing the TZ environment variable.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Playwright adds some custom code to DOM/JS internals to allow an override of the timezone. Just search for SetTimeZoneOverride in the following patch: https://github.com/microsoft/playwright/blob/master/browser_patches/firefox/patches/bootstrap.diff

I had a look if we already have some kind of override capabilities in Gecko, which could make the Playwright patch a no-op. Not sure if we would need it for a given browsing context tree (tab) only. By searching the code base on mozilla-central and talking to some folks I was pointed to this WebExtension:

https://addons.mozilla.org/en-US/firefox/addon/change-timezone-time-shift/

It overrides the window.Intl.DateTimeFormat prototype chain. Not sure if that's ideal.

Otherwise I was pointed out to Cu.getJSTestingFunctions(), which offers getTimeZone() and setTimeZone(). Some usage can be seen here:

https://searchfox.org/mozilla-central/rev/294f10eff7398d6b05beac6aa256d86ac3cb7113/browser/components/urlbar/tests/unit/test_unitConversion.js#462-466

But not sure either if it's a good idea to actually make use of this testing interface here.

Tom, I have seen that you were involved in some timezone specific changed in core code. Do you know if emulating a specific timezone is possible these days via some IDL interfaces?

Comment 2

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Unfortunately, no. At least not that I know of. For RFP we do the TZ variable, and it kind of stinks. We want to let RFP be controlled on a per-origin basis, and the TZ approach makes that impossible. But I started thinking about just this Bug 1709867 and tried to suggest a mechanism that might work. ( At least for RFP. I'm not sure if it would work for what's needed here though.) It looks a little similar to the patch they wrote.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Tom Ritter [:tjr] (OOTO, back June 28) from comment #2)

Unfortunately, no. At least not that I know of. For RFP we do the TZ variable, and it kind of stinks.

That's right but at least would help us to get a step further for the time being. We have similar blockers for networking APIs (like bug 1553849) that we also implemented globally for now.

Bug 1709867 and tried to suggest a mechanism that might work. ( At least for RFP. I'm not sure if it would work for what's needed here though.) It looks a little similar to the patch they wrote.

Do you know if there is anyone (or maybe you) who want to work on that? Or at least whom to ask? If it's not you maybe we could get feedback for the patch for Playwright and if a similar implementation would make sense. No one from our side might actually be able to work on that in the foreseeable future.

Comment 4

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

I'm afraid I don't have the bandwidth to drive this, patch-wise - but I can mentor.

Cu.getJSTestingFunctions() -> getTimeZone() and setTimeZone() merely munge the Environment Variable. This works, but is an overlarge hammer for the job, when I think we can get by with something more focused.

The playwrite patch looks pretty good; two things I noticed reviewing it:

• I think it is not affecting UTCToLocalStandardOffsetSeconds() or utcToLocalStandardOffsetSeconds_. It looks like this will cause issues with date.getFoo.

• I am unsure if js::DateTimeInfo::timeZone() will return the spoofed value or not. It looks like it will but it would be good to be sure.

Although I'm happy to mentor - I am not the correct person to be reviewing this code for landing. We'll need to find that person; perhaps Andre would be willing? (I can also help someone expand upon the playwrite patch to accomplish the RFP side of Bug 1709867 - but that's beyond the scope of this bug.)

Comment 5

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

This may be something my capstone project students due as part of their work this school year.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Hi @brnbs. As discussed on Element it would be great to get a brief overview of what you got implemented and which issues are remaining. By doing that I'm fairly sure that Tom will be able to - at least partially - give some feedback and suggestions. Thanks!

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:whimboo, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit auto_nag documentation.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We are not going to close this bug for now in case someone actually wants to work on it.