[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


https://bugs.webkit.org/show_bug.cgi?id=31718





--- 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?
http://msdn.microsoft.com/en-us/library/bb760252(VS.85).aspx


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