Should EventInit contain 'timestamp'? about dom HOT 16 OPEN

Why?

from dom.

Sorry, let's back up a second, I may be jumping to conclusions based on partial discussions elsewhere. Filed #80 to track the larger issue.

If we decide to do that, then timestamp is no longer an inherent property of the event, but data supplied by the thing that created the event, and as you've argued elsewhere (TouchEvent.pageX I think?) all such properties should be settable via the constructor.

Eg. imagine a PointerEvents polyfill that generates pointermove events from mousemove and touchmove. If timestamp represents the time the input was first received by the OS, then the polyfill should be able to propagate the value from a mousemove into a generated pointermove. There are other similar non-polyfill scenarios involving any synthetic input event.

from dom.

Interesting. I'm no longer sure whether MouseEvent.prototype.offsetX needs to be able to be set or should just be computed on creation time, but your timestamp scenario does somewhat argue for making it settable, or at least for creating an event based on an existing one.

from dom.

Thanks. In addition to copying the timestamp from other events, there are at least some small scenarios where you really want to synthesize a timestamp. Eg. Android and now iOS 9 align input to vsync through position/time interpolation. It's reasonable for a library to want to do something similar taking, say, a 100hz input event source and converting it to a 60hz one phase-locked to requestAnimationFrame. Doing that requires generating events with timestamp values that are interpolated (or perhaps even extrapolated) from the timestamps of other events.

But I think we can wait until we've done the spec updates for #80 to decide exactly what we want to do here.

from dom.

Do we still want this?

from dom.

Seems like this is blocked on #23, right? If the ultimate decision in #23 is that timeStamp should ALWAYS be the time the event object itself was created (i.e. pretty much useless), then there's probably no value in being able to set it by the constructor.

from dom.

I guess we can wait on that.

from dom.

Seems like the path for #23 is pretty clear now (just waiting on tests). Perhaps it's time to revisit this discussion?

Some related context where we have a blink bug because we were internally using the Event constructor code path which didn't have a way of specifying the timestamp.

from dom.

#420 is still ongoing as far as I can tell.

Also, if we add this to the constructor, due to the way event dispatch is defined that would mean that each call site ends up defaulting this to the default value, which is not what we want, so adding this might be more involved than you think.

from dom.

So https://codereview.chromium.org/2834183002 landed without intent to ship? Is it not web-exposed or some such?

from dom.

So https://codereview.chromium.org/2834183002 landed without intent to ship? Is it not web-exposed or some such?

I believe it is not web-exposed yet as it is not in the IDL file: https://codesearch.chromium.org/chromium/src/third_party/WebKit/Source/core/events/EventInit.idl

if we add this to the constructor, due to the way event dispatch is defined that would mean that each call site ends up defaulting this to the default value, which is not what we want, so adding this might be more involved than you think.

I am not sure if I understand the above correctly. The way I was thinking to do this was as follow:
Add timestamp to EventInitDic and have it default to equivalent of "performance.now()"
This means that we will use this default value when 1) create an event is used and 2) when Event constructor is invoked

AFAICT those are the two places where EventInit is used so not sure how the definition of event dispatch algorithm changes this behavior. So this is what I expect to happen:

let e = new MouseEvent(); // N = performance.now
$target1.dispatchEvent(e); // e.timestamp == N
$target2.dispatchEvent(e); // e.timestamp == N

If this makes sense I can start a patch or event better fold this change in #420 (I think using EventInit default value makes #420 wording simpler)

from dom.

So https://codereview.chromium.org/2834183002 landed without intent to ship? Is it not web-exposed or some such?

I believe it is not web-exposed yet as it is not in the IDL file: https://codesearch.chromium.org/chromium/src/third_party/WebKit/Source/core/events/EventInit.idl

Right, the "constructor" mentioned there was C++ code. This was just an internal refactoring to fix a bug we had where timestamps weren't initialized propertly for UA-generated events. It might ultimately share C++ code with a change for this issue, but is otherwise entirely unrelated.

from dom.

@majido shouldn't timestamp reflect when the event happened, not when it's created/dispatched?

from dom.

That is correct. I think the right behavior should be as follow:

1. For synthetic events (those constructed from JS), we should allow the timestamp to be provided to the constructor via EventInitDic as suggested by this issue. But the creation time is a sensible default value.
2. For events created by user agent, the actual occurrence time should be used. And when that is not available, then once again I think falling back to using the creation time is a sensible choice.

I don't think we need to use dispatch time in any case. I might have not be precise before.

from dom.

Okay, so the problem is that we don't make a distinction between synthetic and non-synthetic at creation. So unless we explicitly pass a time in all places that define that the user agent is to dispatch an event, we end up introducing a regression of sorts.

from dom.

@domenic pointed out that we do. https://dom.spec.whatwg.org/#concept-event-fire and https://dom.spec.whatwg.org/#concept-event-create don't go through the constructor and those are the entry points for other standards. (I don't know if that's a good thing long term solution, but it's not a blocker here.)

from dom.