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

[bugzilla-daemon at webkit.org]

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





--- Comment #4 from Darin Adler <darin at apple.com>  2010-02-09 10:40:27 PST ---
(In reply to comment #3)
> > 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.

Tooltips are indeed updated as elements move on the page. I’m not sure about
completion, but I believe they also update.

Neither has an API that involves passing a rectangle to the ChromeClient, so I
don’t think these are similar enough.

Imagine a page where there is a zip code field that appears only if the country
is U.S. You enter some invalid data below and then the user changes the country
to non-U.S.. So the invalid field moves up on the page and the rectangle that
was passed to the ChromeClient is now invalid. How would you suggest this work?

> > 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.

I think we want most of the logic to be in the engine. The more code that
client applications need, the more we’ll have bugs and an unequal playing field
between clients. We want WebKit to be as easy to use as possible. The policy
comes from the client, but as much of the sensible behavior as possible should
be built into WebKit.

Specifically, simple cases like elements going away should not require extra
explicit code in every client.

> > 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) ?

> 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?

The very notion of a one size fits all “validation failed” UI seems a bit
quaint and naive to me.

But I suggest looking for interface in Mac OS X UI that implement this type of
thing. Take a Mac and poke around at the system until you can find something. I
believe there is an example like this when you install Mac OS X and set up your
initial account name and password. Tap some other Mac OS X experts to find some
examples and then we can make an informed decision.

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