Open Bug 1651070 Opened 4 years ago Updated 10 months ago

<input type=number> doesn't deal with dynamic lang changes correctly.

Categories

(Core :: DOM: Core & HTML, defect)

defect

Tracking

()

People

(Reporter: emilio, Assigned: dshin)

References

(Blocks 1 open bug)

Details

It only looks at when the lang attribute changes on itself, but not when it changes on any ancestor, or when it changes trees.

Could you have some comments here?

Flags: needinfo?(mbrodesser)
Priority: -- → P3
Severity: -- → S3
Priority: P3 → --

@emilio: which scenario and which observable errors did you mean?

Interestingly, when running
data:text/html,<div lang="en-GB"><input type="number" step=0.1></input><script>document.querySelector("input").value="123.3"; document.querySelector("div").lang = "de-DE"</script>

"123.3" isn't changed to "123,3", so that seems wrong. When clicking the spinner button to get "123,4", "123,4" is displayed.

Moreover, the <input> accepts values like "123,4" and "123.4", which seems wrong. This suggests ancestor changes are considered, but not correctly.

Flags: needinfo?(mbrodesser) → needinfo?(emilio)

The english / dot syntax is always accepted as required by the spec.

This is even more broken than I thought, because the change on the input itself is not handled correctly.

<!doctype html>
<html lang="es-ES">
<input type="number" step="0.01">
<button onclick="this.previousElementSibling.lang = 'en-GB'">Change on input</button>
<button onclick="document.documentElement.lang = 'en-GB'">Change on root</button>
<button onclick="alert(document.querySelector('input').validity.valid)">Validity</button>

What I would expect to see is any of the two change buttons, after writing e.g. 10,5 in the input, make the input invalid.

But we only have this code to deal with that, which doesn't deal with ancestor changes. But even for the non-ancestor change it's broken, because UpdateValidityState early-returns...

This has never worked correctly. I only filed for tracking, really. I don't think it's terribly important to fix.

Flags: needinfo?(emilio)
Duplicate of this bug: 1804806

Bug 1804806 has test cases that lead to a crash, as well as lang change on input element itself not working correctly unless it's datetime.

Assignee: nobody → dshin

Copying crash signatures from duplicate bugs.

Crash Signature: [@ mozilla::RestyleManager::ElementStateChanged]
See Also: → 1807703

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

This has never worked correctly. I only filed for tracking, really. I don't think it's terribly important to fix.

Update, following up on this assessment from 3 years ago -- nowadays we have some crash volume that we believe to be associated with this issue, making it somewhat more important to fix.

Looking at the last month of bug 1793410's crash volume: nearly half of the crashes (28 out of 62) have MOZ_CRASH Reason (Raw) set to Element state change during style refresh (3072). The numeric value 3072 there is 1<<10 | 1<<11 which is the bit pattern associated with our dupe-bug 1804806.

So: when we fix this bug, we can expect it to address some or perhaps all of that 3072-tagged crash volume from bug 1793410, i.e. as much as half of the crash volume there.

(Assuming the past month is representative: I guess that'd mean that this would avoid ~1 crash per day (28 crashes over 30 days), which I suppose is relatively low. So: this still isn't drop-everything level of severity, but it'd be nice to fix.)

The bug is linked to a topcrash signature, which matches the following criterion:

  • Top 10 AArch64 and ARM crashes on nightly

:dshin, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Flags: needinfo?(dshin)
Keywords: topcrash

Bug 1793410 (which this bug blocks) is really the bug for the [@ mozilla::RestyleManager::ElementStateChanged ] crash signature. This bug just tracks one known way that we can trigger that crash.

I'll move comment 9 over there, and let's remove the [@ mozilla::RestyleManager::ElementStateChanged] crash signature from this bug to avoid attracting more bot bug-tweaks.

Crash Signature: [@ mozilla::RestyleManager::ElementStateChanged]
Flags: needinfo?(dshin)
Keywords: topcrash
You need to log in before you can comment on or make changes to this bug.