11 ms·
Text exceeding maxlength will no longer be truncated when pasted in Firefox 77
- pphysch 6y agoI've definitely been bit by this and it definitely took hours to debug
- Retr0spectrum 6y agoI'm curious, could you describe the usecase?
- fabianhjr 6y agoI 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 6y agoAh. On first read, I assumed you meant you had a webapp which was broken by these changes.
- williamdclt 6y ago(This isn't the same person that answered you)
- PeterisP 6y agoA particular case that I have seen is fields for account numbers that expect X characters, but people are copypasting the numbers from sources where they are represented with extra spaces for readability. (e.g. 1234 5678 instead of 12345678) And when they get to the validation, the last digit(s) have been lost.
- turnipla 6y agoThis breaks my use case function shorten(text, length) const t = document.createElement('input') t.maxlength = length t.value = text return t.value }
- jagged-chisel 6y agoIndeed. I'd suggest a change in this code even if this change in FF hadn't arrived.
- 1f60c 6y agoI 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 6y agoProbably way more efficient than relying on a side effect to a DOM update as well.
- fpoling 6y agoBut it is the Web. Somebody must be using it.
- deleted 6y ago[deleted]
- gruez 6y agowhoosh
- deleted 6y ago[deleted]
- anchpop 6y agoI know you're joking, but this reminded me of https://xkcd.com/1172/ https://xkcd.com/1172/
- Someone1234 6y ago> 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 6y agoA 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 6y agoAnd 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 6y agoAm I missing something? This seems less surprising than the alternative.
- nikanj 6y agoWhy would you have a maxlength on password in the first place?!
- arkadiyt 6y agoIt's common in practice even if it shouldn't be. Also many bcrypt implementations truncate input longer than 72 characters.
- masklinn 6y ago> 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 6y agoA 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 6y ago> 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.
- 0x0000000 6y agoNot sure if this is a title length restriction on HN, but the omitted "...when pasted into..." here seems important.
- 1f60c 6y agoAnd "a password field" also.
- Someone1234 6y agoThat's their justification, not a restriction on the change, this impacts non-password fields too.
- lucb1e 6y agoYeah 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.
- garaetjjte 6y agoEh? For what reason you need to add JS? Forms won't submit with overlong text.
- lucb1e 6y agoOh the change is that it'll not cut the user off but show a warning instead? I misread the post then. Edit: Yes, indeed: > The form cannot be submitted until the user fixes the error, so the server shouldn’t receive an excessively long text Thanks for pointing that out!
- jawns 6y agoIt'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 6y agoYou 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.
- jeroenhd 6y agoFrom 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.
- fireattack 6y agoIn input.html [1] it says >If the input element has a maximum allowed value length, then the length of the value of the element's value attribute must be equal to or less than the element's maximum allowed value length. I'm a little bit confused, Which one should we follow? [1] https://html.spec.whatwg.org/multipage/input.html#attr-input-maxlength https://html.spec.whatwg.org/multipage/input.html#attr-input...
- Majromax 6y agoFrom 4.10.17.1 (https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-fe-value https://html.spec.whatwg.org/multipage/form-control-infrastr...): > A control's value is its internal state. As such, it might not match the user's current input. The example goes on to describe cases where a browser might remove padding spaces from a field, or refuse to register (as a value) a text entry in a numeric field.
- 6y ago
- rkagerer 6y agoHighlights 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-infrastructure.html#limiting-user-input-length:-the-maxlength-attribute https://html.spec.whatwg.org/multipage/form-control-infrastr...
- gbear605 6y agoAs someone whose user agent is Firefox, I’d rather that maxLength didn’t exist at all, and given that it does, my user agent ignoring that seems like the best solution to me.
- 764_OC 6y agoWe 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/$o3a38gf7m-lLpimQ1HY2aYDcTVBwh9cGSBuj3tpVVUw?via=mozilla.org&via=matrix.org&via=synapse.travnewmatic.com https://matrix.to/#/!xSFwJMLGSLXLaSUrHr:mozilla.org/$o3a38gf...
- deleted 6y ago[deleted]
- erichurkman 6y agoNow 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 6y agoIf 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.
- mschuster91 6y agoPreventing people from pasting Word HTML markup into documentEditable inputs (i.e. WYSIWYG editors)!
- lhorie 6y agoCue javascript-based workarounds
- franga2000 6y agoThis 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.
- 764_OC 6y agoYup, that would be awesome, maybe file an enhancement on bugzilla.
- drdec 6y agoWhy 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?
- aasasd 6y agoI'd suggest putting a red background behind the excess text. However, this quickly bumps into websites' customization of input fields.
- cosmotic 6y agoThey 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 6y agoShould they also remove type="number"? It breaks that expectation too.
- aidenn0 6y agoI 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.
- deleted 6y ago[deleted]
- dboreham 6y agoFor some reason I read that as Fortran 77.
- rcxdude 6y agoThis 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.
- speleding 6y agoAt 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-ignores-html-maxlength-attribute https://stackoverflow.com/questions/33080103/ios-safari-igno... [2] https://stackoverflow.com/questions/27319642/is-there-a-workaround-for-text-input-maxlength-not-working-in-safari https://stackoverflow.com/questions/27319642/is-there-a-work...
- Groxx 6y ago>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).