[HN Gopher] Text exceeding maxlength will no longer be truncated...
___________________________________________________________________
Text exceeding maxlength will no longer be truncated when pasted in
Firefox 77
Author : oftenwrong
Score : 121 points
Date : 2020-05-16 17:12 UTC (5 hours ago)
(HTM) web link (www.fxsitecompat.dev)
(TXT) w3m dump (www.fxsitecompat.dev)
| franga2000 wrote:
| 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.
| 764_OC wrote:
| Yup, that would be awesome, maybe file an enhancement on
| bugzilla.
| drdec wrote:
| 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?
| cosmotic wrote:
| 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 wrote:
| Should they also remove type="number"? It breaks that
| expectation too.
| turnipla wrote:
| This breaks my use case function shorten(text,
| length) const t = document.createElement('input')
| t.maxlength = length t.value = text return
| t.value }
| jbverschoor wrote:
| Maybe you should submit a pull request to the npm package where
| that code lives.
| jagged-chisel wrote:
| Indeed. I'd suggest a change in this code even if this change
| in FF hadn't arrived.
| [deleted]
| 1f60c wrote:
| 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 wrote:
| Probably way more efficient than relying on a side effect
| to a DOM update as well.
| fpoling wrote:
| But it is the Web. Somebody must be using it.
| gruez wrote:
| whoosh
| [deleted]
| anchpop wrote:
| I know you're joking, but this reminded me of
| https://xkcd.com/1172/
| marvy wrote:
| Me too. I suspect this was intentional :)
| turnipla wrote:
| This is exactly it!
| [deleted]
| roberto wrote:
| Something similar was used to parse URLs:
| https://stackoverflow.com/questions/6168260/how-to-parse-a-u...
| no_wizard wrote:
| You can just use the URL object now
|
| https://developer.mozilla.org/en-US/docs/Web/API/URL
| 764_OC wrote:
| This change does not affect `t.value` behaviour. :)
| aidenn0 wrote:
| 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.
| jawns wrote:
| 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.
| rkagerer wrote:
| 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
|
| [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1320229
|
| [3] https://html.spec.whatwg.org/multipage/form-control-
| infrastr...
| gbear605 wrote:
| As 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 wrote:
| 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...
| [deleted]
| Someone1234 wrote:
| > 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?!
| lonelappde wrote:
| https://html.spec.whatwg.org/multipage/forms.html#client-sid...
| Someone1234 wrote:
| Your link says to use the very attribute that Mozilla are
| breaking in this change. Can you explain whatever point
| you're trying to make?
| obeattie wrote:
| You just typed your comment into a <form>
| Someone1234 wrote:
| So Mozilla's non-standard compliant change broke one fewer
| site, problem solved?
|
| Even for this site, why is Mozilla not limiting this breaking
| change designed to fix password fields to: Password fields.
| They haven't described why type=text or even textarea should
| be non-standard, only why type=password should be.
|
| If they limited this to password fields, I'd have no issue.
| But per the code change they did not.
| zeroimpl wrote:
| I've had issues pasting phone numbers into text fields,
| where the last digits get cut off because the form doesn't
| want hyphens. I'd rather it paste in the full thing and
| then let me manually remove the hyphens/spaces.
| jeroenhd wrote:
| Even if you use AJAX forms for logging in or registering (I'd
| prefer you didn't but whatever), you should still use the
| proper form validation API for things like this. If you use the
| proper HTML API for gathering data properly, you're most likely
| not affected badly functionality wise; only your UI will be
| affected because the form will refuse to be posted without
| proper explanation.
|
| If the change really does get bypassed by everyone, that only
| underlines the sad state of modern website design relying
| completely on javascript.
|
| I'm not sure why they don't limit this to just passwords but I
| can imagine it's easier to change the behaviour for all form
| elements than it is to change the behaviour of just password
| fields.
| gruez wrote:
| >Even if you use AJAX forms for logging in or registering
| (I'd prefer you didn't but whatever), you should still use
| the proper form validation API for things like this.
|
| You don't even need to use "the proper form validation API".
| It's as simple as changing your ajax call from an onclick (on
| the submit button) to an onsubmit (on the form).
| jeroenhd wrote:
| Agreed. Though, as a developer, I like to extend the
| submission actions a little bit to make error messages fit
| in with the rest of the site and maybe suggest what to do
| in order to correct the input (e.g. remove letters from
| phone numbers, pick a better password, etc.)
|
| I do consider using the HTML5 form validation to be the
| proper validation API. Browser can do a lot without
| javascript and relying on their default behaviour is still
| making use of the validation API.
| unilynx wrote:
| You can do a lot with setCustomValidity to improve error
| messages while still using the rest of the HTML5
| validation API.
| jeroenhd wrote:
| You're totally right, but the Firefox popover indicating
| what's going wrong doesn't go with some of the designs I
| make. On a bootstrap-based design I much prefer
| bootstrap-style error messages which are easy to do with
| Javascript, and the same is true for Material-based
| designs.
|
| I do think that people generally overlook the built-in
| form validation though, and I like to use them as a
| fallback for Javascriptless environments to ensure
| everyone can get proper validation.
| nerdbaggy wrote:
| 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 wrote:
| 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 wrote:
| Am I missing something? This seems less surprising than the
| alternative.
| jeroenhd wrote:
| 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 wrote:
| 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 wrote:
| 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.
| JakeWesorick wrote:
| It's important to use form elements for accessibility even if
| your submitting another way. Also at least for me its a lot
| better to use the built in form validation then creating your
| own.
|
| https://dev.to/addyosmani/accessibility-tips-for-web-develop...
| Someone1234 wrote:
| Your link doesn't support your statement, or even attempt to.
| Screen readers have no concept of <form> elements, nor do
| they differentiate on what happens behind the curtain when a
| button is pressed (e.g. aJax Vs. submit).
|
| If you have an article that does explain your argument,
| please link it.
|
| > Also at least for me its a lot better to use the built in
| form validation then creating your own.
|
| This change removes that very validation.
| tambre wrote:
| >This change removes that very validation.
|
| How? The form can't be submitted until it's fixed.
|
| >The form cannot be submitted until the user fixes the
| error [...]. The user will typically see a red border
| around the text field along with a validation message [...]
| [deleted]
| lhorie wrote:
| Cue javascript-based workarounds
| erichurkman wrote:
| 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 wrote:
| 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 wrote:
| There's also an extension called Don't Fuck With Paste.
| mschuster91 wrote:
| Preventing people from pasting Word HTML markup into
| documentEditable inputs (i.e. WYSIWYG editors)!
| jeroenhd wrote:
| 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 wrote:
| 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 wrote:
| 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...
| fireattack wrote:
| In 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...
| nikanj wrote:
| Why would you have a maxlength on password in the first place?!
| arkadiyt wrote:
| It's common in practice even if it shouldn't be.
|
| Also many bcrypt implementations truncate input longer than 72
| characters.
| grifball wrote:
| If your password is too long to fit in a hash scheme, then
| it's probably secure to just truncate and match. Unless the
| user has little entropy in the first part of their password,
| which i can't see happening.
| monadic2 wrote:
| You can also trivially truncate to 72 bytes server side.
| Dylan16807 wrote:
| That's a horrible thing to do.
|
| If you're really paranoid about cryptography then reject
| it. If you're slightly less paranoid then pass it through
| SHA512 before bcrypting it. Never silently truncate a
| password.
| masklinn wrote:
| > 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 wrote:
| 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.
| [deleted]
| r00fus wrote:
| Truncating at 8 or 12 chars is crazy. Truncating at 30+ is fine
| but still causes edge cases.
| at_a_remove wrote:
| Because someone would inevitably try to submit a four megabyte
| password, or an eight gigabyte password, or whatever.
| danaliv wrote:
| Limit request size and/or time at the HTTP server, and
| validate input on the backend.
| beervirus wrote:
| So you don't have to hash a terabyte of data that some DOS'ing
| asshole sends you.
| [deleted]
| Wowfunhappy wrote:
| ...I think it's reasonable for there to be _some_ limit, right?
| Lest a user submit a 50,000 character password?
| rubyn00bie wrote:
| Nope. Not reasonable, and likely of no benefit to anyone.
| That'd be like 50kb... assuming it doesn't cause your hashing
| algorithm to take a shit causing breakage. 50kb to on one
| request, sitting pretty much at rest 99.9% of the time, is
| nothing to even bother with. Most folks should probably spend
| more time worry about optimizing their own payloads instead
| of their users [1].
|
| [1] To that point, most people want to spend time on useless
| optimizations like truncating a password when they should be
| spending time reducing the size of their images, making sure
| requests are gzipped, or reducing their obscenely complex
| front-end bundle. It's just that most of those optimizations
| which are useful, only make you feel stupid for not
| implementing them sooner because they're obvious and easy,
| while truncating a password feels like YOU outsmarted
| something (when in fact you didn't)
| franga2000 wrote:
| Not allowing a 50k char password is entirely reasonable.
| For one, a sha256 hash of 50kB would take a good quarter of
| a second (possibly more, I just ). That's already
| ridiculous. Some sites also check passwords for dumb things
| like taking the username and doing 1337-type substitutions,
| which would (if implemented badly) take even longer.
|
| More importantly though, a 50k character password is barely
| more secure than a 20 character one, but it gives the user
| a false sense of security. Passwords are inherently flawed
| and we shouldn't kid ourselves that just making them longer
| makes a difference.
|
| If you're in a situation that calls for a 2^400 keyspace,
| you probably shouldn't be using passwords anyways.
| eMSF wrote:
| >For one, a sha256 hash of 50kB would take a good quarter
| of a second (possibly more, I just ).
|
| You're probably thinking 50MB. Hashing 50kB should be
| almost instantaneous.
| [deleted]
| gridlockd wrote:
| What about 500kB? 5mB? At what point _does_ it become
| reasonable to spend a few extra minutes on sanitizing user
| input?
| cxr wrote:
| You haven't answered the question.
|
| > Lest a user submit a 50,000 character password?
|
| What's wrong with that?
| 542458 wrote:
| We'll, at a certain point CPU consumption from hashing a
| sufficiently massive pass would be a concern, no? Like,
| bcrypt is a pretty slow function, although I don't know how
| it scales with input length.
|
| Edit: Hunh, apparently bcrypt only handles 72 chars
| anyways.
| remus wrote:
| You should be doing some fairly expensive hashing if you're
| storing the password correctly. Maybe not an issue for a
| 50k char password, but how about a 50 billion char
| password?
| danaliv wrote:
| This is a backend concern, not a frontend one. The
| backend shouldn't naively accept input without making
| sure the input is within the backend's limitations.
| oefrha wrote:
| Client side validation does not replace server side
| validation, and vice versa. Just because you validate
| server side doesn't mean you can't also do it client side
| and avoid a round trip.
| Dylan16807 wrote:
| I guess? But if someone puts in a ten megabyte password
| they are either suffering a bug or blatantly screwing
| with you. It's okay to throw a 400 error at them.
| cxr wrote:
| > You should be doing some fairly expensive hashing if
| you're storing the password correctly
|
| Exactly. You aren't storing those bytes.
|
| > Maybe not an issue for a 50k char password, but how
| about a 50 billion char password?
|
| We're back to a place where the response to the question
| is another question, but it just ends up failing to give
| an answer, opting to just keep throwing out larger and
| larger numbers. My response: "Yeah, okay. How about it?"
| Why stop at 50 billion? 99 trillion, let's go there next.
| Again: why not?
|
| Because 50 billion chars is over 46 GiB of data. There
| are natural consequences of very large payloads and
| limits that you're going to reach as a result of those
| consequences (e.g. being prohibitively expensive for the
| client to send in the first place, or it will max out the
| server's connectivity lifetimes for extant requests
| before the payload can be delivered). If "CPU utilization
| crosses threshold" is the real reason, then let that be
| the real reason--and let the safeguards you have in place
| for handling those problems do their jobs. And if "we cap
| passwords to X chars" is your safeguard, then you have
| bigger problems.
| 0x0000000 wrote:
| Not sure if this is a title length restriction on HN, but the
| omitted "...when pasted into..." here seems important.
| 1f60c wrote:
| And "a password field" also.
| Someone1234 wrote:
| That's their justification, not a restriction on the change,
| this impacts non-password fields too.
| lucb1e wrote:
| 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 wrote:
| 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 wrote:
| 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 :)
| garaetjjte wrote:
| Eh? For what reason you need to add JS? Forms won't
| submit with overlong text.
| lucb1e wrote:
| Oh 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!
| Wowfunhappy wrote:
| I imagine the goal is to make behavior consistent instead
| of adding weird exceptions.
| dang wrote:
| Seems like "when pasted" can be squeezed in.
| pphysch wrote:
| I've definitely been bit by this and it definitely took hours to
| debug
| Retr0spectrum wrote:
| I'm curious, could you describe the usecase?
| fabianhjr wrote:
| 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 wrote:
| Ah. On first read, I assumed you meant you had a webapp
| which was broken by these changes.
| williamdclt wrote:
| (This isn't the same person that answered you)
___________________________________________________________________
(page generated 2020-05-16 23:00 UTC)