1933351 - datetime-local supports valueAsDate when it shouldn't

Status: RESOLVED FIXED

(Core :: DOM: Forms, defect)

Description

[opliko]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

Used inputElement.valueAsDate when the input type="datetime-local"

Actual results:

It returned a Date object, making me believe the code was correct while it didn't work in browsers that followed the specification more strictly on that front

Expected results:

It should've returned null as per the specification: https://html.spec.whatwg.org/multipage/input.html#dom-input-valueasdate

"On getting, if the valueAsDate attribute does not apply, as defined for the input element's type attribute's current state, then return null."

For datetime-local: https://html.spec.whatwg.org/multipage/input.html#local-date-and-time-state-(type=datetime-local)

"The following IDL attributes and methods do not apply to the element: checked, files, selectionStart, selectionEnd, selectionDirection, and valueAsDate IDL attributes; setRangeText(), and setSelectionRange() methods."

Relevant Chromium issue where returning null was deemed the correct behavior: https://issues.chromium.org/issues/40475290

This is a compatibility issue and it allows for browser detection. It's definitely not a major issue, but I also don't think that (especially considering lack of support for other browsers) it makes much sense leaving a footgun in a somewhat obscure API, where the intuitive usage works only in Firefox.

Comment 1

[opliko]

Also, this was tracking addition of

Comment 2

[opliko]

(apologies for spam, first time using Bugzilla and I submitted previous comment while editing bug metadata)

This bug was tracking the addition of this feature: 1310078
But I don't see any rationale or specification discussion there, nor do I see any mention of valueAsDate in the broader 888331

Comment 3

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

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Henri Sivonen (:hsivonen)]

I can't reproduce this on https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13331

Reporter, do you have a minimized test case?

Comment 5

[opliko]

Apologies for taking so long to respond - but it seems your test case reproduces the issue? Tested on FF135.0b9 (desktop), FF136.0a1 (mobile), FF1340.2 (mobile) and FF Focus 134.0.2 (mobile). All give me the same result - valueAsDate returns a Date object for a fully filled out datetime-local input (note: you need to enter both the date and time to get a value there and FF only shows a date picker, requiring keyboard input for time. If you enter only the date then valueAsDate will be null, but also value will be an empty string.).

Chrome 132.0.6834.122 and Ungoogled Chromium 132.0.6834.110 both correctly return null even when both the date and time are filled for datetime-local inputs, only working with date inputs.

Comment 6

[Andrew McCreight [:mccr8]]

I think I can reproduce the difference the reporter is talking about.

1. Load https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13331
2. In the top date input widget, fill it out completely with 01/01/2000, 5:00 AM
3. Click on print, look at the text produced in the "log" section below.

In Firefox, the output is log: object "Fri Dec 31 1999 21:00:00 GMT-0800 (Pacific Standard Time)" (0 props).
In Chrome, the output is log: object "null" (0 props).

I have no idea how much of a webcompat problem this might be.

Comment 7

[Leo Tenenbaum [:ltenenbaum]]

Attachment: Bug 1933351 - Give null valueAsDate for datetime-local inputs, as spec requires. r=#dom-core

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/ca829b4947f0
https://hg.mozilla.org/integration/autoland/rev/8230b4935231
Give null valueAsDate for datetime-local inputs, as spec requires. r=dom-core,avandolder

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/58191 for changes under testing/web-platform/tests

Comment 10

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/8230b4935231

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 13

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 14

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

The patch landed in nightly and beta is affected.
:ltenenbaum, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox149 to wontfix.

For more information, please visit BugBot documentation.