Disabled date input shows wrong value when cleared programatically
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox81 | --- | fixed |
People
(Reporter: iagosrl, Assigned: saschanaz)
References
Details
(Whiteboard: [layout:triage-discuss])
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
- Choose or set a valid value to a date input
- Disable the input (set attribute 'disabled' at the input element)
- Uses JavaScript to clear the value by assigning and empty string to the 'value' property (when selected at Inspector,
$0.value = ''). - (example as a fiddle https://jsfiddle.net/IagoSRL/t1k9fy4x/16/)
Actual results:
- The input shows still the previously choosen date, as is nothing happened.
- But the 'value' property reports to be an empty string.
- And the 'valueAsDate' reports to be a null value.
Expected results:
- The input should display as empty (no date displayed)
- (note that, if rather an empty string another valid date is set, the display updates properly).
Comment 2•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
| Assignee | ||
Updated•5 years ago
|
| Assignee | ||
Updated•5 years ago
|
| Assignee | ||
Updated•5 years ago
|
Comment 3•5 years ago
|
||
The severity field is not set for this bug.
:jimm, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 4•5 years ago
|
||
I think this should stay in DOM, it does not sound like a widget (rendering) bug.
| Assignee | ||
Comment 5•5 years ago
|
||
clearInputFields() in datetimebox.js is no-op when the element is disabled (isEditable() is false when disabled), so the component.
Comment 6•5 years ago
|
||
Oh, but Widget is about OS level widgets. This is more like a toolkit issue or Core & HTML or Layout.
The parent process side of form elements is vague.
Comment 7•5 years ago
|
||
Fun. It's not really a layout issue though (unless it had to do with widget sizing or styling). Generally the agreement we've had is that functionality of non-OS level widgets would stay in DOM: Core & HTML. I'll leave in Layout for now since we're touching form controls in various ways soon.
| Assignee | ||
Comment 8•5 years ago
|
||
Taking this as I already found the cause in comment #5.
| Assignee | ||
Comment 9•5 years ago
|
||
Comment 10•5 years ago
|
||
Comment 11•5 years ago
|
||
| bugherder | ||
Description
•