It is impossible to select multiple elements in a multiple selection SELECT element by using only the touch screen (no control or shift keys). Is there support for this on other platforms? Is it acceptable to add a build flag such as USE_TOUCH_UI, that would change the behavior on mouse click of the SELECT element under WebCore/dom/SelectElement?
Created attachment 38595 [details] Proposed short term solution till a more elaborate one is available This is a simple solution but it locks behavior at compile time. It has the advantage of not affecting anything if the special flag is not set.
What does the iphone do? I assume it exposes a different form control. Normally this would be an ENABLE #define and defined in platform.h, no? Mark (bdash) on #webkit would know what the current best practices re: #defines are.
(In reply to comment #2) > What does the iphone do? I assume it exposes a different form control. Multi-select lists are drawn as single-select lists in Safari for iPhone, but when you tap on the form control, you get a "wheel" picker that lets you select multiple items in the list. The UI drawing and item selection for the wheel picker is handled above WebCore/WebKit, though. In the long term, it would be better to use an adapter pattern or a base class/child class relationship rather than adding yet another ENABLE() macro.
Comment on attachment 38595 [details] Proposed short term solution till a more elaborate one is available 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.
(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.
I think part of what you're finding is that the iPhone (the first webkit touch device) sources are still not entirely in svn.webkit.org. So the public WebKit still doesn't support touch as well as it should. Patches are certainly welcome to fix that. As you note above, we should come up with a nice architecture to do that.
Comment on attachment 38595 [details] Proposed short term solution till a more elaborate one is available clearing review flag now that this bug is closed.