
Text exceeding maxlength will no longer be truncated when pasted in Firefox 77 - oftenwrong
https://www.fxsitecompat.dev/en-CA/docs/2020/text-exceeding-maxlength-will-no-longer-be-truncated-when-pasted-into-input-or-textarea/
======
turnipla
This breaks my use case

    
    
        function shorten(text, length)
          const t = document.createElement('input')
          t.maxlength = length
          t.value = text
          return t.value
        }

~~~
jagged-chisel
Indeed. I'd suggest a change in this code even if this change in FF hadn't
arrived.

~~~
1f60c
I think GP was joking. A far more straightforward way to shorten text to a
given length is:

    
    
      const shorten = (text, length) => text.substring(0, length);

~~~
seanmcdirmid
Probably way more efficient than relying on a side effect to a DOM update as
well.

~~~
fpoling
But it is the Web. Somebody must be using it.

------
jeroenhd
From the WHATWG/W3C definitions of the maxlength attribute:

> 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 code-unit length of the
> element’s 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 value to be set to a value whose code-
> unit length is greater than the element’s maximum allowed value length.

The key word, I think, is "may" in that user agents do not seem to be
obligated to truncate text from what I can find in the standard.

While this does break the expectations from a developer point of view, I think
it is perfectly in line with what users expect when they paste text. I think
text falling off at the end after a paste with no explanation is more
confusing than an the field glowing red with a message "you can only enter X
characters here".

The old behaviour famously made people lose access to their PayPal account
where the login form had a different maxlength as the registration form and
where the password manager had put in a nice, long password. Preventing this
sounds like a fine change for me, despite the compatibility break.

~~~
contravariant
Arguably truncating the text is against the specification as it only specifies
that the user agent may _prevent_ the user from going beyond the max-length,
not that it may do arbitrary stuff to make the text fit.

I also hope it will make at least some developers realise that client-side
validation is a bad idea.

~~~
jeroenhd
I'd say the fact that it says that the user agent may, not must, truncate the
text is a sign that this behaviour should not be expected. Failing the HTML5
validation is also perfectly reasonable. If people are building web pages
right, this change will have little impact.

Big if, of course, but a man can dream...

------
jawns
It's fairly common to copy a large amount of text and drop it into an input
with length restrictions. For instance, I do it often when I submit HN titles.
For regular text, it's a much better UX to be able to paste the whole thing
then edit it down to meet the restrictions than to paste and have it auto-
truncated.

When it comes to password inputs, where you can't necessarily see what you're
pasting, it's extremely important than the user knows when truncation occurs.
But could that be achieved while still respecting maxlength? Yes, I think it
would be decent UX to alert the user when they attempt to paste text that
exceeds the maxlength, without actually completing the paste. That way, the
input remains empty so there's no confusion about whether the full password or
a truncated password has been entered, and the user can take appropriate
action.

~~~
Olreich
You should just let the password field have kilobytes of data. Throw a
warning, but it costs you almost nothing. You don’t have to store the data,
processing password hashes is designed to take a long time and use a lot of
memory (way more than the password of a few KB).

Your web app should also not engage with the password field as much as
possible. Don’t make it a component, just leave it a password field. Don’t
read it except to immediately send the contents to the server. Bonus points
for just having that be a form submission.

------
rkagerer
Highlights from the bug report[1][2]:

    
    
      - HTML spec allows it; says MAY, not MUST [3]
      - Affects only user pastes, not javascript edits
      - Affects all input boxes, not just password ones
      - New preference editor.truncate_user_pastes can restore old behavior
    

As a developer, I personally find the inconsistent behavior of maxLength
unintuitive and am surprised a potentially-breaking change like this didn't
have more discussion (although, the original bug report was open for 4 years).
But as a user, I have some empathy for the team's desire to fix "broken"
websites (e.g. where the login page has a shorter limit than the account
creation page or backend).

[1]
[https://phabricator.services.mozilla.com/D71689](https://phabricator.services.mozilla.com/D71689)

[2]
[https://bugzilla.mozilla.org/show_bug.cgi?id=1320229](https://bugzilla.mozilla.org/show_bug.cgi?id=1320229)

[3] [https://html.spec.whatwg.org/multipage/form-control-
infrastr...](https://html.spec.whatwg.org/multipage/form-control-
infrastructure.html#limiting-user-input-length:-the-maxlength-attribute)

~~~
764_OC
We discussed the problem on #security and we moved to bugzilla once we kinda
had a solution (it is hard to discuss solutions on bugzilla. :) Here is a link
to the chat:
[https://matrix.to/#/!xSFwJMLGSLXLaSUrHr:mozilla.org/$o3a38gf...](https://matrix.to/#/!xSFwJMLGSLXLaSUrHr:mozilla.org/$o3a38gf7m-lLpimQ1HY2aYDcTVBwh9cGSBuj3tpVVUw?via=mozilla.org&via=matrix.org&via=synapse.travnewmatic.com)

------
erichurkman
Now how can we reclaim `onpaste` events? If I'm in an input box and paste
text, are there any legit use cases of _blocking_ paste of text in text entry
fields?

~~~
pwg
If you are browsing with Firefox, then yes, you can. Set this variable,
"dom.event.clipboardevents.enabled", in about:config to false and websites can
no longer block you from pasting into input fields.

~~~
donatzsky
There's also an extension called Don't Fuck With Paste.

~~~
aitchnyu
Somehow it breaks Slack and Teams as collateral damage. I have to disable DFWP
for certain sites.

~~~
Olreich
Not collateral. They fuck with paste.

------
franga2000
This is a welcome change, but what would make it even more awesome is a little
red bar at the last character that fits into the maxlength. A semi-common
thing I do is paste a long thing of text into an exerpt text area, let it
truncate to maxlength and manually tweak the ending. A little red bar to tell
me where it would've gotten truncated would make that still possible, while
fixing the dangerous behavior with truncating fields.

~~~
drdec
Why not a context menu entry to truncate the content to the correct length?

Or even better, some kind of warning when the paste happens, giving the user
the option of truncating, canceling or continuing anyway?

------
pphysch
I've definitely been bit by this and it definitely took hours to debug

~~~
Retr0spectrum
I'm curious, could you describe the usecase?

~~~
fabianhjr
I have used password-store (pass) to generate passwords and paste them to
forms without realizing they were truncated and simultaneously those sites
don't have the same maxlength on their login form.

~~~
Retr0spectrum
Ah. On first read, I assumed you meant you had a webapp which was broken by
these changes.

~~~
williamdclt
(This isn't the same person that answered you)

------
speleding
At least this behaviour is better than iOS Safari, which will happily send an
input field longer than maxlength to the server. You can find a whole bunch of
StackOverflow questions about this [1][2]. So if you will need a server side
check regardless of what Firefox does. (Of course, you need a server side
check anyway, but you need one with proper feedback rather than throwing back
an "Unacceptable" http status code).

[1] [https://stackoverflow.com/questions/33080103/ios-safari-
igno...](https://stackoverflow.com/questions/33080103/ios-safari-ignores-html-
maxlength-attribute) [2] [https://stackoverflow.com/questions/27319642/is-
there-a-work...](https://stackoverflow.com/questions/27319642/is-there-a-
workaround-for-text-input-maxlength-not-working-in-safari)

------
nikanj
Why would you have a maxlength on password in the first place?!

~~~
arkadiyt
It's common in practice even if it shouldn't be.

Also many bcrypt implementations truncate input longer than 72 characters.

~~~
masklinn
> It's common in practice even if it shouldn't be.

It should be though, the backend should reject overlong passwords, and the
frontend should have such limits as well.

Though by "overlong" I mean kbyte range, not 32 character. The point of the
limitation is to avoid randos feeding megabytes of data into your KDF and
DOSing your server.

> Also many bcrypt implementations truncate input longer than 72 characters.

The alternative would be to error as bcrypt works on 18 words (of 32 bits).
You need special handling (pre-hashing with a non-broken cryptographic hash
function) to fix this issue.

Also it's 72 _bytes_ not characters. And your pre-hash needs to generate some
sort of textual representation (hex, base64, base85, …), as bcrypt will also
truncate at the first NUL byte.

The original paper actually specifies _56_ bytes.

~~~
Dylan16807
A kilobyte limit is fine but

> The point of the limitation is to avoid randos feeding megabytes of data
> into your KDF and DOSing your server.

You shouldn't be using a KDF that takes significantly longer when the password
gets bigger. If you make that mistake, even a kilobyte is going to be
annoyingly slow. If you don't make that mistake, then even MAX_POST_SIZE
passwords won't DOS you.

~~~
masklinn
> You shouldn't be using a KDF that takes significantly longer when the
> password gets bigger.

Your KDF _necessarily_ takes longer when the password gets longer as it's a
hash function and thus O(n).

For typical password sizes (typically under 64 bytes), you're below the hash's
blocksize so the effect is nil and you can treat it as a constant but it
_will_ start coming into play as the size of the key and thus the number of
blocks to feed into the hash increases.

~~~
Dylan16807
A KDF is not a hash function, and I said "significantly" for a reason.

If adding a megabyte of input causes the original megabyte to get hashed or
otherwise processed once, then you pass the test.

If adding a megabyte of input causes the original megabyte to get fed into
your algorithm 100000 times, then you fail the test.

------
aidenn0
I actually ran into a case where the input maxlength on the password field was
longer than the maxlength on the "set password" field. When I used my password
manager I could login, but when I pasted my password, I _couldn 't_ login.

------
rcxdude
This will probably be helpful. I frequently come across fields which have a
tight maxlength where there may or may not be spaces in the field (things like
credit card numbers, sort codes, postcodes). When pasting in a version with
spaces, this frequently deletes parts of the field which are relevant and
required me to delete the spaces and then fill in the result. With this change
I would be able to paste it in and then just delete the spaces.

------
Groxx
> _The form cannot be submitted until the user fixes the error, so the server
> shall not receive an excessively long text or password_

Seems like win/win for everyone. In-spec, less confusing for users, and
doesn't change behavior for normal form submissions (JS submitters are clearly
opting out of browser safety nets).

------
cosmotic
They should remove maxlength altogether; it breaks the expected behavior of
textboses wherein pressing a key when focus is in a textbox inserts the
character corresponding to that key.

~~~
recursive
Should they also remove type="number"? It breaks that expectation too.

------
lhorie
Cue javascript-based workarounds

------
dboreham
For some reason I read that as Fortran 77.

------
0x0000000
Not sure if this is a title length restriction on HN, but the omitted "...when
pasted into..." here seems important.

~~~
1f60c
And "a password field" also.

~~~
Someone1234
That's their justification, not a restriction on the change, this impacts non-
password fields too.

~~~
lucb1e
Yeah that's the weird thing. They write "for password fields" and then apply
it to non-password fields and even multi-line fields. Have you ever seen a
multi-line password field?! I understand that people might abuse <textarea>
for it but that's definitely not the common thing and just crazy talk. It's an
excuse but I don't understand the reason behind this change.

I've been setting maxlength to generous values on my fields in applications
since I started coding HTML, if now suddenly I have to revisit everything and
add JavaScript magic to check form validity where previously the page was
completely free of JS, well, I think I'd frankly refuse where possible and
tell people to complain to their faulty implementation.

~~~
tomsmeding
At the risk of stating the obvious, and sorry if so: doing input length
validation client side is very useful for the user's experience, but the
server should always validate this too. "... now suddenly I have to revisit
everything and add JavaScript magic to check form validity ..." sounds
suspiciously like you were relying on client side form validation without
server validation, I hope that's not the case. :)

~~~
lucb1e
It prevents server-side errors, which I don't handle as gracefully. When the
client sends content that it shouldn't have been able to send (i.e. someone
tampered with the form) and the server bails out, I don't always bother making
it pretty.

I'm well aware of the risks in client-side validation, but indeed, as I see in
my job often enough (I'm a security consultant), it's a valid remark that not
everyone has taken to heart quite yet so thanks for the comment :)

~~~
tomsmeding
Ah yes, preventing uglier server-side errors is indeed a very valid reason. :)

------
Someone1234
> The form cannot be submitted until the user fixes the error, so the server
> shouldn’t receive an excessively long text or password (a server-side
> validation has to be put in place anyway.) However, this could potentially
> affect a front-end implementation if it expects the entered text never to
> exceed maxlength.

What century are Mozilla living in? Most, even simple forms, don't use <form>
elements and submit buttons anymore, they're all aJax. Therefore this
workaround will be commonly bypassed.

People can debate if this is a good or bad thing, but ultimately the problem
remains: This change will cause unexpected behavior when maxlength-ed stuff no
longer obeys on thousands of popular websites.

Even if sites check it server-side, that doesn't mean the user experience
isn't substantially degraded relative to obeying HTML standards.

Their justification for this change is nonsensical too:

> This change mainly aims at preventing an unexpectedly truncated password
> from being saved.

So why not limit it to input type=password? Heck why include textareas in this
change, who is using a textarea for a password box?!

~~~
nerdbaggy
A lot of people still put them in forms. They just intercept the form submit
to do with as the please. No putting them in a form also breaks accessibility

~~~
Someone1234
And a lot of sites don't. "This breaks a ton of things but not everything"
isn't a good attitude to browser compatibility, particularly from a browser
that already has a small market share.

> No putting them in a form also breaks accessibility

Nope. Screen readers have no concept of <form> fields, nor any concept of how
the piping works below the surface when a <button> is pressed. I run a screen
reader every single day.

~~~
renewiltord
Am I missing something? This seems less surprising than the alternative.

~~~
jeroenhd
One breaks the expectations of users, the other breaks the expectations of
developers. On a website full of developers you'll probably see a lot more
from one side than from the other.

~~~
Someone1234
I'm pretty sure being able to input text longer than the maximum allowable
text into a field breaks user's expectations too. Users don't "win" because
you made how a site works more confusing.

Their justification for this change is the only user-win (password
truncation), and they could have trivially restricted this to passwords then
body is hurt.

~~~
edoceo
Users don't expect the length limit! that info isnt presented to them until
the text is over-long and the clue is: Surprise! Truncate w/o warning. On more
than just password fields.

