Intent to Prototype: Add timezonechange event to Window/WorkerGlobalScope

103 views
Skip to first unread message

Frank Tang

unread,
Jan 7, 2020, 6:28:57 PM1/7/20
to blink-dev, Daniel Ehrenberg, Mathias Bynens, Nebojša Ćirić, Frank Yung-Fong Tang
ft...@google.com https://github.com/whatwg/html/pull/3047 Specification: https://github.com/whatwg/html/pull/3047 https://docs.google.com/document/d/1gu-HAVIjVxfPQEE0uQg9Y4tJwYl33Y54DKTA9hfDyic/edit# Add a timezonechange event and ontimezonechange event handler to Window/WorkerGlobalScope. The current timezone is visible to JavaScript and changes over time. Changes may be useful to note, e.g., in a long-running calendar or mail application that may want to update dates and times without refreshing when the user resumes using the application after travel. Currently, to accomplish that, a webapp would have to poll, e.g., by repeatedly calling Intl.DateTimeFormat().resolvedOptions().timeZone.
Lack of negative signals from other browser vendors Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals
Yes No To be decided https://www.chromestatus.com/feature/5766713599590400
This intent message was generated by Chrome Platform Status.
Message has been deleted

Yoav Weiss

unread,
Jan 8, 2020, 2:12:01 AM1/8/20
to Frank Tang, blink-dev, Daniel Ehrenberg, Mathias Bynens, Nebojša Ćirić, Frank Yung-Fong Tang
Have you filed for a TAG review? 
 
Add a timezonechange event and ontimezonechange event handler to Window/WorkerGlobalScope. The current timezone is visible to JavaScript and changes over time. Changes may be useful to note, e.g., in a long-running calendar or mail application that may want to update dates and times without refreshing when the user resumes using the application after travel. Currently, to accomplish that, a webapp would have to poll, e.g., by repeatedly calling Intl.DateTimeFormat().resolvedOptions().timeZone.
Lack of negative signals from other browser vendors Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals

Can you reach out to other vendors and partners to get some signals on this?

e.g. as far as partners go, I can see calendar apps interested in using this
 
Yes No To be decided

Can you expand on that?
 
https://www.chromestatus.com/feature/5766713599590400
This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL8Z0spwW6X8Js1smNwPHb0yXDq-XvAqdK7g6VkEp5NMPg%40mail.gmail.com.

Mathias Bynens

unread,
Jan 9, 2020, 3:59:13 AM1/9/20
to Yoav Weiss, Frank Tang, blink-dev, Daniel Ehrenberg, Nebojša Ćirić, Frank Yung-Fong Tang, ann...@annevk.nl
On Wed, Jan 8, 2020 at 8:11 AM Yoav Weiss <yo...@yoav.ws> wrote:


On Wed, Jan 8, 2020 at 12:28 AM Frank Tang <ft...@chromium.org> wrote:

Have you filed for a TAG review? 
 
Add a timezonechange event and ontimezonechange event handler to Window/WorkerGlobalScope. The current timezone is visible to JavaScript and changes over time. Changes may be useful to note, e.g., in a long-running calendar or mail application that may want to update dates and times without refreshing when the user resumes using the application after travel. Currently, to accomplish that, a webapp would have to poll, e.g., by repeatedly calling Intl.DateTimeFormat().resolvedOptions().timeZone.
Lack of negative signals from other browser vendors Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals

Can you reach out to other vendors and partners to get some signals on this?

The relevant spec PR has positive signals from browser vendors:

Firefox: the helpful involvement by both annevk@ and chrisdavidmills@ implies Mozilla's support. I've filed https://github.com/mozilla/standards-positions/issues/241 asking for explicit confirmation.

Additionally, the W3C I18N WG expressed support: https://github.com/whatwg/html/pull/3047#issuecomment-432107919
 
e.g. as far as partners go, I can see calendar apps interested in using this

Indeed, calendar apps, but also event websites that render their schedule in the user's timezone (e.g. https://developer.chrome.com/devsummit/schedule/) could benefit from this.

Yoav Weiss

unread,
Jan 9, 2020, 4:09:30 AM1/9/20
to Mathias Bynens, Frank Tang, blink-dev, Daniel Ehrenberg, Nebojša Ćirić, Frank Yung-Fong Tang, Anne van Kesteren
On Thu, Jan 9, 2020 at 9:59 AM Mathias Bynens <mt...@google.com> wrote:


On Wed, Jan 8, 2020 at 8:11 AM Yoav Weiss <yo...@yoav.ws> wrote:


On Wed, Jan 8, 2020 at 12:28 AM Frank Tang <ft...@chromium.org> wrote:

Have you filed for a TAG review? 
 
Add a timezonechange event and ontimezonechange event handler to Window/WorkerGlobalScope. The current timezone is visible to JavaScript and changes over time. Changes may be useful to note, e.g., in a long-running calendar or mail application that may want to update dates and times without refreshing when the user resumes using the application after travel. Currently, to accomplish that, a webapp would have to poll, e.g., by repeatedly calling Intl.DateTimeFormat().resolvedOptions().timeZone.
Lack of negative signals from other browser vendors Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals

Can you reach out to other vendors and partners to get some signals on this?

The relevant spec PR has positive signals from browser vendors:


Great! Thanks for pointing it out! :)
 
Firefox: the helpful involvement by both annevk@ and chrisdavidmills@ implies Mozilla's support. I've filed https://github.com/mozilla/standards-positions/issues/241 asking for explicit confirmation.

Thanks for filing an official request for Mozilla's standards position. In the past we were told that supportive opinions from individuals there don't necessarily imply support from Mozilla as a whole.


Additionally, the W3C I18N WG expressed support: https://github.com/whatwg/html/pull/3047#issuecomment-432107919

Great to have that wide review feedback! 

Daniel Ehrenberg

unread,
Jan 9, 2020, 10:52:09 AM1/9/20
to Yoav Weiss, Frank Tang, blink-dev, Mathias Bynens, Nebojša Ćirić, Frank Yung-Fong Tang
On Wed, Jan 8, 2020 at 8:11 AM Yoav Weiss <yo...@yoav.ws> wrote:


Have you filed for a TAG review?

We have not filed a TAG review yet. This proposal was stalled for a while due to lack of implementer interest; now's probably a good time to file if such interest exists, but one open issue is holding the project up a bit.

There was one open specification question: whether the timezone update should be delayed until the event is about to fire. Delaying the update seems most consistent with how events work in general, and I imagine could be useful to maintain application consistency but I wasn't sure if this would be implementable or useful in practice. For example, if the update is delayed, it is probably impossible to use underlying system APIs to do timezone calculations with this change, as Chrome did until recently, and some browsers still might do. If I were to just choose an answer at this point, I would probably choose to delay the tz update, as most people in the thread preferred, though Frank voiced some concerns about this and said he's planning on investigating further.

I would recommend against shipping this event until we come to a conclusion on this question which has been discussed in a standards context. I was planning on waiting to draft the final spec text and request the TAG review until after we had an answer. Please let me know if you want me to file a request sooner, explaining it as an open question, or to just choose an answer to this question in the PR and file a TAG review based on that.

Thanks,
Dan
Message has been deleted

Daniel Ehrenberg

unread,
Jan 9, 2020, 12:21:59 PM1/9/20
to Yoav Weiss, Frank Tang, blink-dev, Mathias Bynens, Nebojša Ćirić, Frank Yung-Fong Tang
On Thu, Jan 9, 2020 at 4:51 PM Daniel Ehrenberg <litt...@chromium.org> wrote:

I would recommend against shipping this event until we come to a conclusion on this question which has been discussed in a standards context

Just to clarify, what I meant by this was circling back on the WHATWG issue, letting people know the proposed conclusion, and seeing briefly if others have any thoughts.

Dan

Jeffrey Yasskin

unread,
Jan 9, 2020, 2:49:53 PM1/9/20
to Frank Tang, blink-dev, Daniel Ehrenberg, Mathias Bynens, Nebojša Ćirić, Frank Yung-Fong Tang, Nick Doty
Nick Doty pointed out that if this event fires at the same time across
all open tabs, the timestamp of that event becomes a cross-origin
tracking vector. I believe this is fixed if the event is delayed until
the user next activates that tab. If that much delay isn't acceptable,
there may be a way to fire the events earlier if they're spread across
enough time, but I don't immediately know how much spread is needed.

Thanks Nick!

Jeffrey

Nick Doty

unread,
Jan 9, 2020, 4:06:29 PM1/9/20
to Jeffrey Yasskin, Frank Tang, blink-dev, Daniel Ehrenberg, Mathias Bynens, Nebojša Ćirić, Frank Yung-Fong Tang
This issue was previously noted by the Firefox team on the Idle API [0] (2012), for Proximity and Ambient Light sensors [1] (2013) (and is still noted in the generic Sensor API [2]) and for device changes in Media Capture [3] (2016) (where it’s limited to cases where specific permissions are already granted, and where fuzzing is noted as a mitigation).

Mitigations could include limiting firing to visible tabs and to top-level browsing contexts (as in sensors), limiting firing to cases where permissions have already been noted (as in device attachments), or potentially fuzzing in time. We should probably consider these mitigations in the spec, although it looks like the privacy/security tag was removed during the design process.

Thanks,
Nick

[0] https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/7mEN0gSryCk
[1] https://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0007.html
[2] https://w3c.github.io/sensors/#focused-area
[3] https://github.com/w3c/mediacapture-main/issues/333

Frank Tang

unread,
Jan 9, 2020, 4:07:03 PM1/9/20
to Nick Doty, Jeffrey Yasskin, blink-dev, Daniel Ehrenberg, Mathias Bynens, Nebojša Ćirić, Frank Yung-Fong Tang
I am not familiar with the frame structure and refcounting in chrome code base. 
Is there someone that can I help me if I have some specific questions about how to wire the events? 

Thanks

Elliott Sprehn

unread,
Jan 9, 2020, 11:06:52 PM1/9/20
to Daniel Ehrenberg, Yoav Weiss, Frank Tang, blink-dev, Mathias Bynens, Nebojša Ćirić, Frank Yung-Fong Tang


On Thu, Jan 9, 2020, 7:52 AM Daniel Ehrenberg <litt...@chromium.org> wrote:
On Wed, Jan 8, 2020 at 8:11 AM Yoav Weiss <yo...@yoav.ws> wrote:


Have you filed for a TAG review?

We have not filed a TAG review yet. This proposal was stalled for a while due to lack of implementer interest; now's probably a good time to file if such interest exists, but one open issue is holding the project up a bit.

There was one open specification question: whether the timezone update should be delayed until the event is about to fire. Delaying the update seems most consistent with how events work in general,

Uncancellable change events like this often happen after, and are not coupled with the update. Ex. Scrolling, orientation change, online, offline, etc. The spec just queues an event and if polling you can observe the change sooner. It's not like the browser waits to issue any network requests until the online event is about to fire. :) I'm not sure in general "something changed" events have precise timing. Certainly with throttling in background tabs they're often very delayed.

and I imagine could be useful to maintain application consistency but I wasn't sure if this would be implementable or useful in practice. For example, if the update is delayed, it is probably impossible to use underlying system APIs to do timezone calculations with this change, as Chrome did until recently, and some browsers still might do. If I were to just choose an answer at this point, I would probably choose to delay the tz update, as most people in the thread preferred, though Frank voiced some concerns about this and said he's planning on investigating further.

I would recommend against shipping this event until we come to a conclusion on this question which has been discussed in a standards context. I was planning on waiting to draft the final spec text and request the TAG review until after we had an answer. Please let me know if you want me to file a request sooner, explaining it as an open question, or to just choose an answer to this question in the PR and file a TAG review based on that.

Thanks,
Dan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages