User Agent: Mozilla/5.0 (Android 9; Mobile; rv:75.0) Gecko/75.0 Firefox/75.0

Steps to reproduce:

Install Firefox for Android Nightly 200214 08:03 (Build #2015722947) 32.0.0, 9ff30b22e
GV: 75.0a1-20200213035745

Go to https://reg-game.netlify.com/

Click "play alone"

Try to type "16" in a cell

Actual results:

A single "1" appears in the cell

Expected results:

"16" appears in the cell

This reproduces on desktop Firefox. Seems like a poorly coded website.

I cannot reproduce it on Firefox desktop nor Firefox for Android stable, or any other browser. It seems like a regression.

well…

<input 
    class="numbox svelte-3p3mko" 
    pattern="1|2|3|4|5|6|7|8|9|10|11|12|13|14|15" 
    title="Values you can play here: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15." 
    type="number" 
    max="16" min="1" 
    step="1" 
    maxlength="1">

it's written on the tin.
maxlength="1"

The issue is why safari tech preview and chrome canary accepts to get a number even with maxlength="1"

This was fixed 17 years ago? by boris
https://bugzilla.mozilla.org/show_bug.cgi?id=190425

What is the spec saying https://html.spec.whatwg.org/multipage/input.html#attr-input-maxlength

The maxlength attribute, when it applies, is a form control maxlength attribute.

Following https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-maxlength

Constraint validation: If an element has a maximum allowed value length, its dirty value flag is true, its value was last changed by a user edit (as opposed to a change made by a script), and the JavaScript string length of the element's API value is greater than the element's maximum allowed value length, then the element is suffering from being too long.

User agents may prevent the user from causing the element's API value to be set to a value whose JavaScript string length is greater than the element's maximum allowed value length.

It doesn't seem a hard constraint, but

results for type='number'

1. enter into the url bar

data:text/html,<input type='number' maxlength='2'/>

2. type 123

Results in different browsers

• firefox: 12 (75.0a1 (2020-02-18) (64-bit))
• chrome: 123 (Version 82.0.4062.4 (Build officiel) canary (64 bits))
• safari: 123 (Release 100 (Safari 13.2, WebKit 15610.1.2.1))

results for type='text'

data:text/html,<input type='text' maxlength='2'/>

Results in different browsers

• firefox: 12 (75.0a1 (2020-02-18) (64-bit))
• chrome: 12 (Version 82.0.4062.4 (Build officiel) canary (64 bits))
• safari: 12 (Release 100 (Safari 13.2, WebKit 15610.1.2.1))

So that looks like a bug in Chrome and Safari, more than Firefox. Maybe there are bugs already opened there.

slightly related but more about the type invalid type being entered, so probably a new issue to create on chromium
https://bugs.chromium.org/p/chromium/issues/detail?id=365196

let's see webkit. no issue related to this issue.
https://bugs.webkit.org/buglist.cgi?bug_status=__open__&content=maxlength&no_redirect=1&order=Importance&product=WebKit&query_format=specific

that would be a good addition to web platform tests too.

I filed

• webkit https://bugs.webkit.org/show_bug.cgi?id=207981
• blink https://bugs.chromium.org/p/chromium/issues/detail?id=1054251

ah interesting I had missed this
tkent commented on the chromium issue.
https://bugs.chromium.org/p/chromium/issues/detail?id=1054251#c2

https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number)

The following content attributes must not be specified and do not apply to the element: accept, alt, checked, dirname, formaction, formenctype, formmethod, formnovalidate, formtarget, height, maxlength, minlength, multiple, pattern, size, src, and width.

So we might have an issue.

Oh! I wouldn't have reported this bug if I had noted the maxlength=1 in the first place ><
But I'm glad it ended up not being a waste of time, since it seems to be a real spec-conformance bug.

What is interesting is that the behavior changed recently:

• firefox 75.0a1 : affected
• firefox 73.0.1 : not affected

[Tracking Requested - why for this release]:
web compat regression

Emilio, looks like bug 981248 broke this. We just about haven't shipped this yet - can you take a look?

Ophir LOJKINE, thank you very much for reporting this!

I suspect we want to change TextControlState::GetMaxLength and nsTextControlFrame::GetMaxLength to return -1 for number inputs. I wonder whether we can just move this into the InputType thing and then use the fact that number inputs don't use the text control input type...

Depends on D63460

The reference (https://html.spec.whatwg.org/multipage/input.html) has a table summarizing which input types maxlength applies to: Text, Search, URL, Telephone, E-mail, Password. All the other types (not only "Number") are unaffected by maxlength. It may be worth checking if this bug also affects other input types.

Yeah, it doesn't because the others don't use the text-editing code... Maybe I could make it more explicit and check for them anyway, or assert it's not called for those types...

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

Yeah, it doesn't because the others don't use the text-editing code... Maybe I could make it more explicit and check for them anyway, or assert it's not called for those types...

This is not what I am seeing. For instance, I can reproduce the bug with <input type='month' maxlength='2'/>.

Well that's a good catch. That's because we don't implement an special layout box for <input type=month>... hmmp...

Yes, that's the point: maxlength shouldn't apply by default everywhere the default text input UI is used, but only when the specification says so.

I revised the patch to be closer to the spec, but we should probably just check for <input type=number> for the beta patch.

This checks only for number rather than InputType::MinAndMaxLengthApply, which
is probably safer to uplift to beta.

Comment on attachment 9127842 [details]
Bug 1616620 - maxlength shouldn't apply to <input type=number> - beta version. r=smaug!

Beta/Release Uplift Approval Request

• User impact if declined: comment 0
• 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: comment 0, or <input type="number" maxlength="1"> and typing
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Relatively self-contained patch. Intentionally only checking for number to restore previous behavior, instead of the central patch which is slightly different to be closer to the HTML spec.
• String changes made/needed: none

Comment on attachment 9127842 [details]
Bug 1616620 - maxlength shouldn't apply to <input type=number> - beta version. r=smaug!

Low risk webcompat fix with tests, uplift approved for 74.0b6, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/a3821c450eca
https://hg.mozilla.org/releases/mozilla-beta/rev/fa7093948ee9

https://hg.mozilla.org/mozilla-central/rev/00f7625a4423
https://hg.mozilla.org/mozilla-central/rev/7a4a562094c5

Reproduced the initial issue using an old Nightly build 75.0a1 (Build id: 20200213035745) using Windows 10.
Verified - Fixed in latest Nightly 75.0a1 (Build id: 20200220224950) and Beta 74.0b6 (Build id: 20200221001238) using Windows 10, Mac OS 10.14 and Ubuntu 18.04.