1804879 - The Calendar can no longer be openened by clicking the Datepicker fields

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Rares Doghi, Desktop QA]

Found in

• 109.0a1 (2022-12-09)

Affected versions

• Firefox Nightly 109.0a1 (2022-12-09)

Affected platforms

• All

Steps to reproduce

1. Reach url: data:text/html,<input type='datetime-local'>
2. Click on any of the available fields.(dd/mm/yyyy hh:mm)

Expected result

• Users should be able to open the Calendar by clicking on the Datepicker fields

Actual result

• User can no longer open the calendar using mouse clicks.
  The Calendar modal will only open if the user clicks the Calendar button or uses the Space bar on one of the fields.

Regression range
8:45.85 INFO: No more integration revisions, bisection finished.
8:45.85 INFO: Last good revision: 99052dd249cc79a752aeed699b8cb4633f3d2cd9
8:45.85 INFO: First bad revision: fe7d9416e64121a3e2b356311b669f2a53052e7b
8:45.85 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=99052dd249cc79a752aeed699b8cb4633f3d2cd9&tochange=fe7d9416e64121a3e2b356311b669f2a53052e7b

Comment 1

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

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

For more information, please visit auto_nag documentation.

Comment 2

[Anna Yeddi [:ayeddi]]

This change is not a regression, but a feature that was discussed and approved by UX (KatieC) this past spring. As the date and datetime-local inputs have a specific affordance now to open a datepicker dialog - the Calendar button - it was deemed unnecessary to keep the click functionality on the field, because a mouse user is likely to click on the field to focus it to type in the value and, if the calendar/picker function is needed, they can click the Calendar button

Picker, when opened, would cover an area under the input field which may include the field's constraints, error message, etc. While it is dismissable on Escape, mouse users are not expected to be aware of this shortcut, if a picker is triggered on click anywhere, they would have the picker showing even if they do not need/want it. This would affect users with cognitive difficulties the most who won't have the under the field information (constraints, errors) in front of them because of the picker. Delegating the management of a picker visibility to a specific button should make it clearer to a user that the calendar is, in fact, available and to allow the user to decide if they want to open/close the picker panel or not.

Thus, the actual results are the expected results in this case.

Emilio, is it okay if we close this ticket? I assume, it's a wontfix category in this case

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Yes, if this is an intentional change, lacking a strong argument for the previous behavior, we can call this WONTFIX/INVALID (in the works as intended sense).