The Calendar can no longer be openened by clicking the Datepicker fields
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox107 | --- | unaffected |
firefox108 | --- | unaffected |
firefox109 | - | wontfix |
People
(Reporter: rdoghi, Unassigned)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: regression)
Found in
- 109.0a1 (2022-12-09)
Affected versions
- Firefox Nightly 109.0a1 (2022-12-09)
Affected platforms
- All
Steps to reproduce
- Reach url: data:text/html,<input type='datetime-local'>
- 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
Updated•2 years ago
|
Comment 1•2 years ago
|
||
:ayeddi, since you are the author of the regressor, bug 1676068, could you take a look?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Comment 2•2 years ago
|
||
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•2 years ago
|
||
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).
Updated•2 years ago
|
Description
•