Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

textarea default maxLength is incorrect #2927

Open
apalaniuk opened this issue Mar 28, 2020 · 2 comments
Open

textarea default maxLength is incorrect #2927

apalaniuk opened this issue Mar 28, 2020 · 2 comments

Comments

@apalaniuk
Copy link

Basic info:

<textarea>s have a default maxLength of 0, which is a valid maximum allowed value length indicating that users can't enter text. As a result, code that inspects maxLength (eg. testing libraries simulating user input which may restrict input events based on maxLength) may consider 0 to mean "no limit" to support jsdom, which makes support across both jsdom and browsers difficult.

In contrast, <input> elements have different behaviour, which will return a reasonably high value when no value has been set (while modern browsers tend to use -1, is still reasonable).

  • Node.js version: 10.16.3
  • jsdom version: 16.2.1

Minimal reproduction case

const { JSDOM } = require('jsdom');

const { document } = new JSDOM(`
    <html>
        <textarea></textarea>
        <input/>
    </html>`
).window;

const textAreaMaxLength = document.querySelector('textarea').maxLength;
const inputMaxLength = document.querySelector('input').maxLength;

console.log(`textarea maxLength: ${textAreaMaxLength}`);
console.log(`input maxLength: ${inputMaxLength}`);

How does similar code behave in browsers?

https://jsfiddle.net/9sdzb2xc/
@apalaniuk apalaniuk mentioned this issue Mar 28, 2020
Closed
@domenic
Copy link
Member

domenic commented Mar 30, 2020

This is just a bug in jsdom, and in particular in our reflection support. The spec says

The maxLength IDL attribute must reflect the maxlength content attribute, limited to only non-negative numbers.

and

If a reflecting IDL attribute has a signed integer type (long) that is limited to only non-negative numbers then, on getting, the content attribute must be parsed according to the rules for parsing non-negative integers, and if that is successful, and the value is in the range of the IDL attribute's type, the resulting value must be returned. If, on the other hand, it fails or returns an out of range value, or if the attribute is absent, the default value must be returned instead, or −1 if there is no default value.

We should be able to fix this relatively easily with the new reflection infrastructure @TimothyGu has put in place. However, we should probably wait until #2926 lands first to avoid merge conflicts...

@kentcdodds
Copy link

A workaround I just found for this for now is:

Number(textarea.getAttribute('maxlength') ?? -1)

That seems to work well enough :)

@thibsy thibsy mentioned this issue Feb 28, 2023
Merged
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@domenic @kentcdodds @apalaniuk