Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

fxsitecompat.dev

Post reply on HN
Print view View original

51–60 of 145 posts

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#51

Post by 542458 »

cxr wrote: post #49
Wowfunhappy wrote: post #35

Earlier quoted context omitted.

...I think it's reasonable for there to be some limit, right? Lest a user submit a 50,000 character password?

You haven't answered the question. > Lest a user submit a 50,000 character password? What's wrong with that?

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.

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#52

Post by lucb1e »

tomsmeding wrote: post #42
lucb1e wrote: post #25

Earlier quoted context omitted.

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 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…

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. :)

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 :)

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#53

Post by remus »

cxr wrote: post #49
Wowfunhappy wrote: post #35

Earlier quoted context omitted.

...I think it's reasonable for there to be some limit, right? Lest a user submit a 50,000 character password?

You haven't answered the question. > Lest a user submit a 50,000 character password? What's wrong with that?

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?

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#54

Post by jbverschoor »

turnipla wrote: post #3

This breaks my use case function shorten(text, length) const t = document.createElement('input') t.maxlength = length t.value = text return t.value }

Maybe you should submit a pull request to the npm package where that code lives.

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#55

Post by rubyn00bie »

Wowfunhappy wrote: post #35
nikanj wrote: post #15

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

...I think it's reasonable for there to be some limit, right? Lest a user submit a 50,000 character password?

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)

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#58

Post by [deleted] »

rubyn00bie wrote: post #55
Wowfunhappy wrote: post #35

Earlier quoted context omitted.

...I think it's reasonable for there to be some limit, right? Lest a user submit a 50,000 character password?

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 sp…

[deleted]

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#59

Post by gruez »

jagged-chisel wrote: post #4
turnipla wrote: post #3

This breaks my use case function shorten(text, length) const t = document.createElement('input') t.maxlength = length t.value = text return t.value }

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

whoosh

Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77

#60

Post by 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.
Post reply on HN