[Webkit-unassigned] [Bug 31718] Framework to show form validation message for invalid controls

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Feb 8 23:34:12 PST 2010


--- Comment #3 from TAMURA, Kent <tkent at chromium.org>  2010-02-08 23:34:12 PST ---
(In reply to comment #2)
> (From update of attachment 48145 [details])
> > +    void mayShowValidationMessage();
> > +    void mayHideValidationMessage();
> A single update function would be better than these two.

ok, I'll merge them into updateValidationMessage(const String&).

> > +    // A validation message for this element is shown.
> > +    bool m_validationMessageShown : 1;
> For boolean data members we normally use a name that fits the sentence "form
> control element <xxx>".
> But I think what you may need here is a copy of the message that was last sent
> to the client, rather than just a boolean.
> > +        virtual void showFormValidationMessage(const Node*, const IntRect&, FrameView*, const String&) { };
> > +        virtual void hideFormValidationMessage(const Node*) { };
> Should be HTMLFormControlElement* instead of Node*. Also no good reason to use
> const Node* since these objects are in a tree and const pointers are not all
> that useful.
> No semicolons after "{ }".
> I don’t understand the value of the IntRect and FrameView arguments. What
> rectangle? What guarantees that a form element is rectangular, given that it
> can be transformed arbitrarily? Why can’t the caller get things like the
> rectangle and view from the form control element using the usual APIs instead
> of having them explicitly passed? Maybe this is best for the current usage in
> Chromium but I don’t think it’s quite right. I would leave all that complexity
> out of the chrome client hookup.

Ah, I didn't take care of transformation. You're right. We shouldn't provide a
rectangle here.

> Further, if you pass a rectangle and frame view, then who is responsible for
> calling with a new rectangle if the page changes? It's clearly wrong to send a
> rectangle for one moment in time without providing for tracking over time, and
> it's not useful to supply the FrameView since it can easily be derived.
> If the validation interface is going to be shown overlaying the web page, I’d
> like to see more support for it in WebKit itself. It’s unpleasant to have to
> redo this feature for each platform separately. It’s good to have flexibility
> but ideally we would share as much common code as necessary.

I see. However I don't have any idea how to support.
I thought validation messages were similar to tooltips or history completions.
They don't have common support code.

> I’m not sure it makes sense to have separate hide/show calls for this -- this
> should instead just be a single set function. All the logic would end up
> simpler and we can use either a null or empty string to mean "hide".
> Is the client guaranteed to receive a call for a form element if it’s removed
> from the document? What about when a document moves out of the view or back
> into the view during navigation? I think that sending the call at destructor
> time is clearly bad, because these are reference-counted times and the timing
> of the call to the destructor is unpredictable. More thought needs to go into
> this aspect of the design.

I assumed ChromeClient implementations were responsible for them.  That is to
say, the implementations may hide validation messages even if
hideFormValidationMessage() is not called.

> How can we test this? Can you hook this up to DumpRenderTree? I don’t think we
> should land the ChromeClient level alone without the upper level hookup that
> allows testing.

Hmm, how about introducing
layoutTestController.visibleValidationMessage(element) ?

> What prevents the same validation message from being repeatedly sent to the
> client?

It never happens because of the code in HTMLFormControlElement.cpp.  If
HTMLFormControlElement has a visible message string as you advised, we can
double-check it.

BTW, I suppose a validation message is shown as "Balloon Tooltip" in Windows,
and couldn't find such UI control for Mac. Do you have any idea on Mac UI?

I'll update the patch later (a few days or more).

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list