1797139 - input element stopped working after change type from date to datetime-local

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[info]

Attachment: input element after type change

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0

Steps to reproduce:

Have this element:
<input name="from" id="from" title="Začátek" value="" type="date" class="input-text required-entry" aria-required="true">

Change type with this jquery code:
$('#from').prop('type', 'datetime-local');

Actual results:

Input element is unusable (attached image).

Expected results:

Element should change type and accept data from user.

Comment 1

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

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

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Thanks for the bug report! I can reproduce something like this. Here's a reduced testcase that triggers the issue for me. In my case, the "test" input ends up collapsing to nearly-nothing (just the "x") after the dynamic tweak.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot of "bad" rendering of testcase 1

Comment 4

[Daniel Holbert [:dholbert]]

Tiaan tracked down a regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5af1fe905b87d9b1662b0de9336d2280ccafc73a&tochange=35362dccb42a5e4b39c851f7aa86c8a9e2952a91

...which points to bug 1734221, which indeed changed some localization related stuff around datetime input fields. Maybe there's a race condition and we're failing to look up the localized format/fields here?

(That bug landed for 106, so that means we've shipped this regression to release.)

Comment 5

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

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

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1797139 - Don't null out l10n from destructor(). r=dholbert,Gijs

destructor() should really clean-up after setup(), not the
constructor(), since setup() can be called multiple times.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/35fe1522cb09
Don't null out l10n from destructor(). r=dholbert,Gijs

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9300291 [details]
Bug 1797139 - Don't null out l10n from destructor(). r=dholbert,Gijs

Beta/Release Uplift Approval Request

• User impact if declined: Fixes layout of datetime <input>s when switching types.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See test-case attached.
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Very straight-forward fix.
• String changes made/needed: none
• Is Android affected?: Yes

Comment 9

[Emilio Cobos Álvarez (:emilio)]

(In reply to info from comment #0)

Thanks for the report. As a workaround, you can set type to text before datetime-local. That should avoid hitting the bug.

Comment 10

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

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

Comment 11

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/35fe1522cb09

Comment 12

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

Upstream PR merged by moz-wptsync-bot

Comment 13

[Ardelean Oana, Desktop QA [:oardelean]]

I managed to reproduce this issue on a 2022-10-25 Nightly build on Ubuntu 22, using the testcase from Comment 2. Verified as fixed on Nightly 108.0a1(build ID: 20221026224258) on Ubuntu 22, macOS 12, Windows 10.

Comment 14

[Donal Meehan [:dmeehan]]

Comment on attachment 9300291 [details]
Bug 1797139 - Don't null out l10n from destructor(). r=dholbert,Gijs

Approved for 107.0b6.

Comment 15

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/051e1a802fe7

Comment 16

[Ardelean Oana, Desktop QA [:oardelean]]

I managed to reproduce this issue on Firefox 107.0b5(build ID: 20221025185841) on Windows 10 using the testcase from Comment 2. Verified as fixed on Firefox 107.0b6(build ID: 20221027185833) on Windows 10, macOS 12, Ubuntu 22.

Comment 17

[Daniel Holbert [:dholbert]]

Per discussion with RyanVM, let's get this into the next dot release as well.

Comment 18

[Daniel Holbert [:dholbert]]

Comment on attachment 9300291 [details]
Bug 1797139 - Don't null out l10n from destructor(). r=dholbert,Gijs

Beta/Release Uplift Approval Request

• User impact if declined: Broken layout of datetime <input>s when switching types.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See test-case attached.
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Very straight-forward fix.
• String changes made/needed: none
• Is Android affected?: Yes

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9300291 [details]
Bug 1797139 - Don't null out l10n from destructor(). r=dholbert,Gijs

Approved for 106.0.4.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/361327979fae

Comment 21

[Ardelean Oana, Desktop QA [:oardelean]]

I confirm this fix is verified on Firefox 106.0.4(build ID: 20221102214123) on macOS 12, Windows 10, Ubuntu 22.