Closed Bug 582248 Opened 9 years ago Closed 9 years ago

@list should ensure that the options displayed satisfy validation constraints

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set

Tracking

()

RESOLVED WONTFIX
Tracking Status
blocking2.0 --- -

People

(Reporter: dzbarsky, Assigned: mounir)

References

Details

No description provided.
Assignee: nobody → dzbarsky
Depends on: 345624, 555840, 556007
So, basically, we should add
NSIMETHOD isValid(const nsAString& aValue, PRBool* result) const;
to ns[I]ConstraintValidation and do the necessary changes to ns[I]ConstraintValidation implementors.
Yes. The only thing that we need to watch out for is that this should be available for our JS components, but we don't expose this to arbitrary JS.  jst suggested adding a function in DOMWindowUtils that would call isValid for us.
Duplicate of this bug: 595267
So, specifications ask us to filter invalid values showed by the list attribute
and our current implementation do not do that.

Jonas thinks we should not do that because authors will be limited in the way
they can use the list attribute like showing just part of a value. For example,
different domain names for email. A domain name isn't a valid email value.

IMO, we should do that because I don't think the list should be used to provide
a part of a value and selecting an invalid value might be confusing for the
user (form being un-submittable because of that). In addition, some websites
might have generated values for which they don't know the validity.
However, we might want to not filter the values if the form element has the
novalidate attribute set. But that could be weird because of the
un-consistency.

Anyway, I think this should block betaN or final because it would be easy to
fix (or to not fix if that's the decision) and it would prevent us to ship a
buggy feature (even if the bug isn't major).
Blocks: 556007, 344614
blocking2.0: --- → ?
No longer depends on: 555840, 556007
David, would you like to work on it if a change is needed?
David, I'm taking this bug given that you told me you don't have so much time these days.
Assignee: dzbarsky → mounir.lamouri
For what it's worth, I don't think we should do this at all. I started a thread in whatwg:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028680.html
I do not agree with points 1 and 3 but I definitely agree that point 2 can be problem and it sounds useless to waste cycles to check something that will be correct most of the time.

Anyway, let's wait and see if some people on the list have strong opinions/arguments.
Status: NEW → ASSIGNED
(In reply to comment #7)
> For what it's worth, I don't think we should do this at all. I started a thread
> in whatwg:
> 
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028680.html

Given that we got only one answer, what should we do? Jonas, did you open a bug in the w3c bug tracker? Do you want me to do that?
Jonas, did you open a W3C bug by any chance?
(FWIW, I don't think we should block on that)
Not blocking on this per previous comments.
blocking2.0: betaN+ → -
Given the performance implication, I'm marking this WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
FTR, the specifications changed and this is no longer mentioned (WHATWG HTML r5725).
You need to log in before you can comment on or make changes to this bug.