- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Mon, 04 Apr 2011 14:00:32 -0400
- To: Matt Brubeck <mbrubeck@mozilla.com>, Benjamin Poulain <benjamin.poulain@nokia.com>, Sangwhan Moon <smoon@opera.com>, "public-webevents@w3.org" <public-webevents@w3.org>
Hi All, Below, Matt proposes a solution. If anyone disagrees, please speak up; otherwise, I think we should consider Matt's proposal as agreed (and he can implement his proposal in the spec). Sangwhan - I also copied your response to this thread below. It appears Matt's proposal is consistent with what you said. Please clarify. -Thanks, ArtB On Apr/2/2011 10:09 AM, ext Matt Brubeck wrote: > On 03/28/2011 01:22 PM, Benjamin Poulain wrote: >> From my experience on the issue with Qt on Windows 7, this mixing of >> mouse event and touch event make it impossible to do anything useful >> with the page. >> >> The best solution I had was to discard the mouse event generated by the >> platform for the touch event. This way the touch and mouse on the same >> computer work as expected. > > I agree. In order to support this technique, I think the Touch Events > spec should at least specify: > > "If the user agent dispatches both touch events and mouse events in > response to the same user action, then the 'touchstart' event must be > dispatched before any mouse events for that action." > > This allows content to support both mouse and touch events, and switch > between them dynamically in a clean way. (For example, this would > allow our own test suite to detect non-touch-aware browsers.) It is > also compatible with existing implementations. Any objections? On Mar/29/2011 4:39 AM, ext Anders Höckersten wrote: > On Mon, 28 Mar 2011 18:44:07 +0200, Matt Brubeck <mbrubeck@mozilla.com> wrote: > >> There is a related issue on browsers that support both touch and mouse input - for example, Firefox 4 on Windows 7 tablets. >> >> On platforms like Windows, the operating system may translate touch input into mouse movements. This means that, instead of one "mousemove" event happening after the "touchend" event, mousemove events and touchmove events are interleaved. (Maybe these mouse events should be suppressed if preventDefault() is called on one or more of the touch events?) >> >> [removed text Matt left in by mistake] >> >> I'm not yet clear enough about this problem to enter any issues in Track, but I'd like to hear other thoughts. > > I can add that QT also has this behavior of sending both mouse events and touch events, at least on some systems[1]. > > I'm leaning towards wanting to ignore system mouse events that are generated for touch events, and let the browser handle emulation of mouse events by itself. The reason is that I don't see why website makers should have to worry about the specific touch/mouse behavior of different OSes (beyond having to cater to both touch and mouse separately, of course), but perhaps I'm missing something here? > > /Anders > > [1] http://doc.trolltech.com/latest/qtouchevent.html#mouse-events-and-the-primary-touch-point
Received on Monday, 4 April 2011 18:01:26 UTC