Should <input type=date> have a "input activation behavior" defined?

[stephenmcgruer]

Currently there is no "input activation behavior" defined for <input> type=date: https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date)

As per https://html.spec.whatwg.org/multipage/input.html#input-activation-behavior, this means that the "activation behavior" for <input> type=date is to do nothing:

The activation behavior for input elements are these steps:
    1. If this element is not mutable, then abort these steps.
    2. Run this element's input activation behavior, if any, and do nothing otherwise.

This means that (as far as I understand it) when a synthesized click() event occurs (i.e. with isTrusted = false), step 19.1 of the "Dispatching Events" algorithm (https://dom.spec.whatwg.org/#concept-event-dispatch) should simply do nothing:

19. If activationTarget is non-null, then:
    1. If event’s canceled flag is unset, then run activationTarget’s activation behavior with event.
    ....

As such, my understand is that by the spec synthesizing a click() event on an type=date should do nothing.

However, the current state of the browser space for this is entirely inconsistent! See the attached test, which has the following results for a synthesized click:

Chrome Desktop (both 62.0.3202.75 and 64.0.3260.2): Synthesizing a click() causes no UI or focus change.
Chrome Mobile (Android, 62.0.3202.84): Synthesizing a click() causes a datepicker widget to be shown to the user.

Firefox Desktop (Nightly 59.0a1): Synthesizing a click() causes a datepicker widget to be shown.
Firefox Mobile (Android, Nightly 59.0a1): Synthesizing a click() causes no UI or focus change.

This inconsistency across browsers caused the following webcompat bug: webcompat/web-bugs#7294

[stephenmcgruer]

(The file is attached as a zip because GitHub refuses to let me upload a .html. See also the web-hosted version at https://output.jsbin.com/sonopow/quiet)
input_type_date.zip

[stephenmcgruer]

Results for Safari and Edge (via Browserstack, versions unknown):

Safari Desktop: Appears not to support <input type=date>. Javascript reports the type of the input as text.
Safari iOS: Synthesizing a click() causes no UI or focus change. However synthesizing a focus() does cause a datepicker widget to be shown!

Edge Desktop: Synthesizing a click() causes no UI or focus change. (Manually clicking on the <input type=date> does show an overlay so there is support there.)

[domenic]

The spec seems pretty clear it should not. This follows from how the spec does not prescribe any particular date picker UI, so saying that one should pop up leads to unpredictable experiences, as you've found.

It sounds like you've found some good browser bugs though! Do you need help filing them?

[flackr]

@domenic I'm not sure I follow your argument. Given the spec allows the user agent to provide an interface for selecting a date, it seems to me that it would be more consistent to say that if the user agent provides one, it should display it on activation consistent with the user manually activating the input.

In terms of compatibility, given that both mobile chrome and mobile safari have a way to show the datepicker widget programmatically it seems likely to me that many mobile sites will have come to rely on this to show a datepicker on tapping some custom UI. IMO, we should spec activation showing the UI, but perhaps collecting usage statistics would help inform this decision?

[domenic]

No, in general the .click() method is not meant to trigger user interfaces, especially in cases where it's a UI/implementation detail that clicking triggers an input at all. For example, you could implement a browser that shows the picker on hover, or on focus, and for those this behavior would make no sense. So its inclusion in those mobile browsers is an interoperability hazard, as you've already found by comparing them to desktop browsers. So that's why this is definitely a browser bug.

[dtapuska]

I believe input type=file also behave this way but selects don't. So there isn't a clear answer here. Since there isn't much interoperability here in any browser we should try to evaluate what sites are doing it and why. When we removed it for selects and we had a few minor reports but it was fine. However we had to leave it in for webviews because a few webview apps were broken.

[stephenmcgruer]

@dtapuska Agreed. I've opened http://crbug.com/786480 for getting data on the Chrome side.

Regarding type=file, in that case the browsers appear to be unified, against the spec. Firefox (mobile and desktop) and Chrome (mobile and desktop) all show a filepicker UI when a synthesized click() is received on an <input type=file>. I have not tested Safari or Edge for type=file.

[foolip]

The use counters are in M65 and results will be here:
https://www.chromestatus.com/metrics/feature/timeline/popularity/2329
https://www.chromestatus.com/metrics/feature/timeline/popularity/2330
https://www.chromestatus.com/metrics/feature/timeline/popularity/2331
https://www.chromestatus.com/metrics/feature/timeline/popularity/2332
https://www.chromestatus.com/metrics/feature/timeline/popularity/2333

The "untrusted" ones aren't zero, so they might go up a bit when this reaches stable.

[foolip]

I have tested https://output.jsbin.com/sonopow/quiet on Edge 16 and Safari TP.

In Edge it doesn't cause the date picker to be shown, and in Safari it seems like <input type=date> isn't supported, and https://caniuse.com/#feat=input-datetime agrees, so obviously calling click() doesn't do anything.

In other words, Firefox is the outlier. We should file a Firefox bug and close this issue, I think. Anything I've overlooked?

[foolip]

Oh, @stephenmcgruer also tested that in #3232 (comment), I saw #3232 (comment) and assumed nobody had. Happily our results were the same though.

[stephenmcgruer]

Sorry, I'm not clear how Firefox is the outlier here? Chrome does different things on desktop vs mobile, which do you think is correct?

[foolip]

Oh, I didn't pay attention to the platform differences. In the absence of specified "activation behavior" the right-per-spec thing is that click() does nothing. To add activation behavior seems odd, because at least in Chrome pressing space and enter doesn't do the same thing as clicking. If we could get away with it, just not having activation behavior seems better to me.

[foolip]

But... what advice could we give to anyone who currently uses click() like this? Is there an alternative?

[miketaylr]

Note: we matched other UAs behavior in https://bugzilla.mozilla.org/show_bug.cgi?id=1443958, starting in Firefox 61+ (assuming it doesn't get backed out).

[stephenmcgruer]

So @domenic and I briefly chatted about this recently, and without wanting to put words in his mouth, I believe we agreed that we are all sympathetic to the use-case (opening date pickers programatically seems useful), but that the data doesn't really support doing anything other than bringing Chrome Android in-line with the rest of the web.

The notable UseCounters (posted above) are:

date picker by trusted click - https://www.chromestatus.com/metrics/feature/timeline/popularity/2329
date picker by untrusted click - https://www.chromestatus.com/metrics/feature/timeline/popularity/2330
date picker ignored untrusted click - https://www.chromestatus.com/metrics/feature/timeline/popularity/2331

These are all very low; 0.004 for the most popular (date picker by trusted click).