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)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla2.0b8
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: mounir, Assigned: mounir)
Details
(Keywords: dev-doc-complete)
Attachments
(1 file)
9.38 KB,
patch
|
sicking
:
review+
|
Details | Diff | Splinter Review |
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•14 years ago
|
blocking2.0: --- → ?
Blocking since this is breaking websites.
blocking2.0: ? → beta9+
Assignee | ||
Comment 2•14 years ago
|
||
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).
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•14 years ago
|
||
Sure, it was planned. I just need to take the time to explain our plan.
Assignee | ||
Comment 5•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Keywords: dev-doc-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Comment 6•14 years ago
|
||
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•14 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.
Comment 8•14 years ago
|
||
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•14 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.
Comment 10•14 years ago
|
||
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•14 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•14 years ago
|
Keywords: dev-doc-complete
You need to log in
before you can comment on or make changes to this bug.
Description
•