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

RESOLVED FIXED in mozilla2.0b8

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: mounir, Assigned: mounir)

Tracking

({dev-doc-complete})

Trunk
mozilla2.0b8
dev-doc-complete
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

Attachments

(1 attachment)

(Assignee)

Description

7 years ago
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
(Assignee)

Updated

7 years ago
blocking2.0: --- → ?
Blocking since this is breaking websites.
blocking2.0: ? → beta9+
(Assignee)

Comment 2

7 years ago
Created attachment 491840 [details] [diff] [review]
Patch v1

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)
Attachment #491840 - Flags: review?(jonas) → review+
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.
(Assignee)

Comment 4

7 years ago
Sure, it was planned. I just need to take the time to explain our plan.
(Assignee)

Updated

7 years ago
Depends on: 613027
(Assignee)

Updated

7 years ago
No longer depends on: 613027
(Assignee)

Comment 5

7 years ago
Pushed:
http://hg.mozilla.org/mozilla-central/rev/77d32c00769c
Status: ASSIGNED → RESOLVED
Last Resolved: 7 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.
(Assignee)

Comment 7

7 years ago
(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
(Assignee)

Comment 9

7 years ago
(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.
Keywords: dev-doc-needed → dev-doc-complete

Comment 11

7 years ago
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+
Keywords: dev-doc-complete
(Assignee)

Updated

7 years ago
Keywords: dev-doc-complete
You need to log in before you can comment on or make changes to this bug.