Closed Bug 613021 Opened 14 years ago Closed 14 years ago

Don't make an element invalid if the value length is higher than the maxlength value

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b8
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: mounir, Assigned: mounir)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

It broke compatibility given that maxlength was available in HTML4 and some websites set the value .value.

This should block given that some forms are broken.

This is going to be reverted in Firefox 4 with these bugs: bug 613016 and bug 613019
blocking2.0: --- → ?
Blocking since this is breaking websites.
blocking2.0: ? → beta9+
Attached patch Patch v1Splinter Review
This patch also prevent maxlength from making textarea invalid even if the retro-compat is probably less touchy for textarea's (maxlength wasn't working in 3.6 with textarea's, it has been added with HTML5 specs).
Assignee: nobody → mounir.lamouri
Status: NEW → ASSIGNED
Attachment #491840 - Flags: review?(jonas)
Please send a comment to the list making it clear in no uncertain terms that we don't consider it compatible with the web to enforce length checks on script-set values and so we won't implement it.
Sure, it was planned. I just need to take the time to explain our plan.
Depends on: 613027
No longer depends on: 613027
Pushed:
http://hg.mozilla.org/mozilla-central/rev/77d32c00769c
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Keywords: dev-doc-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Not sure what needs documenting here. I recognize there's a behavior change, but it sounds like we're just reverting it to work the way it did before, and it's a subtlety that's not documented.
(In reply to comment #6)
> Not sure what needs documenting here. I recognize there's a behavior change,
> but it sounds like we're just reverting it to work the way it did before, and
> it's a subtlety that's not documented.

Indeed, https://developer.mozilla.org/en/DOM/ValidityState hasn't been done yet so I guess this doesn't need dev-doc but that means bug 345624 wasn't fully documented.
ValidityState is documented, it's just got a weird name. I've renamed the page. But I still am not clear on what needs documenting here, from a developer standpoint. https://developer.mozilla.org/en/DOM/ValidityState
(In reply to comment #8)
> ValidityState is documented, it's just got a weird name. I've renamed the page.
> But I still am not clear on what needs documenting here, from a developer
> standpoint. https://developer.mozilla.org/en/DOM/ValidityState

tooLong can never be true because an element can't suffer from being too long now.
OK, now I see. I've added a note to that effect. Thanks for your patient explanation.
As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if  you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)
blocking2.0: beta9+ → betaN+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: