1712384 - Feature request: monotonic timestamps for webRequest.*, webNavigation.*, and proxy.onRequest events

Status: NEW

(WebExtensions :: Request Handling, enhancement, P5)

Description

[Jonathan Mayer]

In the WebExtensions API, webRequest.*, webNavigation.*, and proxy.onRequest events have a timeStamp property. The timestamp is set with the system clock, which introduces a clock change risk—the user or operating system might adjust the clock between when the event fires and when the extension applies logic to the event timestamp. Firefox (and Chrome and Safari) previously addressed this issue for DOM events by migrating from system clock timestamps (Date.now()) to monotonic clock timestamps (performance.now()), which do not have clock change risks.

https://developer.mozilla.org/en-US/docs/Web/API/Event/timeStamp
https://searchfox.org/mozilla-central/source/dom/events/Event.cpp#713

I would like to propose a similar approach for timeStamp-ed events in WebExtensions. To prevent breakage and preserve cross-browser compatibility, rather than changing the semantics of timeStamp (like with DOM events), it might be preferable to add an additional monotonic timestamp for these events (e.g., performanceTimeStamp or monotonicTimeStamp). The implementation burden for providing monotonic timestamps would likely be minimal.

https://searchfox.org/mozilla-central/source/toolkit/components/extensions/webrequest/WebRequest.jsm#260
https://searchfox.org/mozilla-central/source/toolkit/components/extensions/parent/ext-webNavigation.js#113
https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ProxyChannelFilter.jsm#289

Rally is a use case for monotonic timestamps in WebExtensions. Studies use numerous background script and content script timestamps, preferring monotonic timestamps where supported to avoid clock change risks.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Request Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Rob Wu [:robwu]]

We cannot use performance.now() because timeStamp is documented to be "The time when this event fired, in milliseconds since the epoch." - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onBeforeRequest

A consistent timestamp, e.g. since the start of the browser sounds reasonable however. But it carries the risk of being unsynchronized with Date.now() in an extension. On the other hand, we don't document that the timestamp is comparable with Date APIs in extensions.

Chrome for example, even goes further and documents timestamps as follows:

The timestamp property of web request events is only guaranteed to be internally consistent. Comparing one event to another event will give you the correct offset between them, but comparing them to the current time inside the extension (via (new Date()).getTime(), for instance) might give unexpected results.
~ https://developer.chrome.com/docs/extensions/reference/webRequest/#timestamps

Patches are welcome

Comment 3

[Jonathan Mayer]

Attachment: patch.diff

Here's an initial patch, which adds a performanceTimeStamp property to the relevant WebExtensions events and updates the relevant schemas.

Comment 4

[Rob Wu [:robwu]]

Why are you introducing a new property instead of modifying the existing one? Isn't it feasible to change the implementation of timeStamp?

And please use Phabricator instead of an attachment here. For instructions, see https://wiki.mozilla.org/WebExtensions/Contribution_Onramp#Submitting_a_Patch

Comment 5

[Jonathan Mayer]

(In reply to Rob Wu [:robwu] from comment #4)

Why are you introducing a new property instead of modifying the existing one? Isn't it feasible to change the implementation of timeStamp?

A few reasons.

• Maintaining backward compatibility. Timestamps on the system clock aren't safely comparable to timestamps on the High Resolution Time shared monotonic clock, because the user or operating system might make large or non-monotonic adjustments to the system clock at any time for any reason. Extension logic for timeStamp properties would have to depend on the version of Firefox (i.e., comparing the value to Date.now() in older versions and performance.timeOrigin + performance.now() in newer versions).
• Maintaining cross-browser compatibility. Otherwise, for the same reasons, extension logic for timeStamp properties would have to change depending on the browser (i.e., comparing the value to Date.now() in other browsers and performance.timeOrigin + performance.now() in Firefox).
• Accounting for High Resolution Time spec noncompliance. There are currently implementation issues with performance.timeOrigin and performance.now() in the major browsers (see https://github.com/mdn/content/issues/4713). These issues matter for some use cases and don't for others. Using a separate property allows extensions to continue using the system clock if issues with the shared monotonic clock are blockers.
• Avoiding ambiguity. Browser timing is messy, in part, because of ambiguous naming and semantics for clocks and timestamps.

And please use Phabricator instead of an attachment here. For instructions, see https://wiki.mozilla.org/WebExtensions/Contribution_Onramp#Submitting_a_Patch

Glad to use Phabricator if this direction makes sense.

Comment 6

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

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.