[Webkit-unassigned] [Bug 28679] Touch and <SELECT multiple> do not play well

[bugzilla-daemon at webkit.org]

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


Carol Szabo <carol.szabo at nokia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|                            |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED




--- Comment #5 from Carol Szabo <carol.szabo at nokia.com>  2009-09-09 06:35:13 PDT ---
(In reply to comment #4)
> (From update of attachment 38595 [details])
> Aren't there other areas of code which would want to share a define like this? 
> Maybe this on some platforms needs to be a runtime decision?  Should this be
> something asked of a Client interface instead of being a compile option?  I'm
> considering for example Mac OS X, which when run on different devices (like the
> iphone) might want different behavior, touch vs. not.
> 
> I think this patch has sat in the queue because you've not yet convinced a
> reviewer that this is the right approach. Yes, it works, but it looks like a
> hack.

Eric,
I am totally with you. I have submitted this bug and later the fix, in order to
elicit discussion about the subject, which I finally managed to obtain. I tried
for about 3 days on the IRC (webkit and qtwebkit channels) before submitting
the bug to find out what is the webkit policy for touch (that is whether webkit
is willing to provide a default implementation that clients can override, or it
will aim at being an input method agnostic library, which deals in abstract
events such as text entry and selection, element focusing and activation, view
scrolling rather than key down or mouse moved, or which middle road is it
willing to take).
I hate middle road approaches as they tend to creep one way or another and it
is hard to defend one middle road against another, but I understand that
keyboard and mouse events are part of the HTML standard (unfortunately) and
thus they must be supported while touch is not, which makes a distinction for
now.
I, finally, came to the conclusion that the consensus is that touch is going to
be supported as an input method exclusively by the client, and that is OK with
me.

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