1811554 - Calendar does not open on click on input type=date on some non-EN locales (eg KR)

Status: RESOLVED WONTFIX

(Core :: Layout: Form Controls, defect)

Description

[Asif Youssuff]

From https://www.reddit.com/r/firefox/comments/10gcuw4/input_type_date/

Steps to reproduce:

0. export LANG=ko_KR.UTF-8
1. Open https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date
2. Click on date picker on page

What happens:

Calendar does not appear.

Expected result:

Date picker should appear on click.

Regression window:

3:42.23 INFO: Narrowed integration regression window from [99052dd2, f365f6d8] (3 builds) to [99052dd2, fe7d9416] (2 builds) (~1 steps left)
3:42.23 INFO: No more integration revisions, bisection finished.
3:42.23 INFO: Last good revision: 99052dd249cc79a752aeed699b8cb4633f3d2cd9
3:42.23 INFO: First bad revision: fe7d9416e64121a3e2b356311b669f2a53052e7b
3:42.23 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=99052dd249cc79a752aeed699b8cb4633f3d2cd9&tochange=fe7d9416e64121a3e2b356311b669f2a53052e7b

Comment 1

[Asif Youssuff]

[Tracking Requested - why for this release]: Regression in date picker on some international locales.

Comment 2

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

Set release status flags based on info from the regressing bug 1676068

:ayeddi, since you are the author of the regressor, bug 1676068, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 3

[Anna Yeddi [:ayeddi]]

Hi Asif,
the date picker used to be shown on a click anywhere within an input, because there were no other affordance for a mouse user to open it. But as with the bug 1676068 the Calendar button was introduced, a mouse user is able to open the picker by clicking on it. At the same time, a mouse user need to click on the input if they want to type the date in, but the date picker used to appear and possibly cover another content that was after the input: for instance, an inline error that would help users, especially ones with cognitive difficulties, with correcting their entry in the field.

So the on-click activation of the date picker for the editable fields was removed by this patch that replaced the Reset button with Calendar one. This is an expected behavior across different locales.

Does the picker appear by clicking on the Calendar button in the LANG=ko_KR.UTF-8 locale?

Comment 4

[Asif Youssuff]

(In reply to Anna Yeddi [:ayeddi] from comment #3)

Does the picker appear by clicking on the Calendar button in the LANG=ko_KR.UTF-8 locale?

Anna, it does for me , but I am reaching out to the original reporter.

Comment 5

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

The bug is marked as tracked for firefox109 (release) and tracked for firefox110 (beta). However, the bug still isn't assigned.

:fgriffith, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Comment 6

[kristof_de_laet]

This change unfortunately breaks our UX completely. I understand why you changed the click behaviour but it would be nice if this was optional or some alternatives were provided.
We are using the native input datepicker but have overwritten some styling to make the input field itself fit in our designs.
For us the calendar symbol is on the left instead of the right. This used to work perfectly but now a user is supposed to click somewhere on the right where there is no calendar symbol so we will have to fix this if no correction/solution on this behaviour will follow.
In chrome for example, I can spread the native datepicker symbol across the full width by adding styles to -webkit-calendar-picker-indicator, I can't find a similar property to use in firefox, could you maybe help out here?

Comment 7

[Emilio Cobos Álvarez (:emilio)]

(In reply to kristof_de_laet from comment #6)

This change unfortunately breaks our UX completely. I understand why you changed the click behaviour but it would be nice if this was optional or some alternatives were provided.
We are using the native input datepicker but have overwritten some styling to make the input field itself fit in our designs.
For us the calendar symbol is on the left instead of the right. This used to work perfectly but now a user is supposed to click somewhere on the right where there is no calendar symbol so we will have to fix this if no correction/solution on this behaviour will follow.

Can you elaborate / attach an example of what you wanna achieve? You can restore the previous behavior with something like:

input.addEventListener("click", e => input.showPicker())

to show the picker, or on a custom icon or something. Would that not work?

Comment 8

[Emilio Cobos Álvarez (:emilio)]

(for the above comment, sorry)

Comment 9

[kristof_de_laet]

First of all, thank you for your swift response.

What I basically would like to keep is the behaviour we had that was working fine across all browsers.
Allow the use to click anywhere on this input to open the calendar instead of only allowing the user to click on the calendar icon.

In chrome and safari I can adjust the css via -webkit-calendar-picker-indicator to make the calendar icon full width and therefor the whole input field becomes clickable. (the native input is made invisible and replaced by a custom design so it doesn't matter if it looks bad)
For firefox I didn't need to do anything since untill recently the full input was clickable. It would be nice if I could use the same solution across all browsers so for me, and I can imagine many others, the perfect solution would be a similar one to the webkit solution where I can modify the native css of the clickable calendar icon.

I didn't know input.showPicker() has become available by now as well but I do see it's not available yet for safari so that would not be my preferred option.

For the record, I'm not talking about new code I'm writing but we discovered degraded behaviour on our existing platform when using firefox 109, the impact for us is not too high right now but I can imagine others being impacted as well by this change. Of course we want to fix this as soon as possible but first would like to see if you would accept this as an issue as well and would be willing to make changes.

Also sorry that this is maybe not exactly to correct place to discuss this but I it is very much related to what was being discussed in this bug ticket

Comment 10

[kristof_de_laet]

basically, all we had to do for webkit browser to make the full input clickable and open the calendar wit our own input positioned on top of it was add this css to the native input

  input[type=date] {
    padding: 0;
   opacity: 1;
   &::-webkit-calendar-picker-indicator {
      width: 100%;
      height: 100%;
      margin: 0;
  }
}

Comment 11

[kristof_de_laet]

opacity had to be 0 ofcourse :)

Comment 12

[Emilio Cobos Álvarez (:emilio)]

(In reply to kristof_de_laet from comment #10)

basically, all we had to do for webkit browser to make the full input clickable and open the calendar wit our own input positioned on top of it was add this css to the native input

That is extremely hacky, and we're not willing to implement a prefixed pseudo-element for this. Given that and the context in comment 9, I think the right thing to do is using .showPicker() on the input (if available). Something like this should work in all showPicker-supporting browsers:

<!doctype html>
<style>
  #container {
    display: inline-block;
    border: 1px solid red;
  }
  input {
    padding: 0;
    opacity: 0;
  }
</style>
<div id="container">
  <input type=date>
</div>
<script>
  document.querySelector("input").addEventListener("click", function(e) {
    this.showPicker();
    e.preventDefault();
  });
</script>

For safari you still need that CSS hack, but everything ends up working out because showPicker() would throw and not preventDefault the event.

Comment 13

[Anna Yeddi [:ayeddi]]

Thank you for crafting a possible workaround, :Emilio!

Closing this bug because it is an expected behavior (as described in the comment #3) and the custom workaround is provided in the comment #12