[Webkit-unassigned] [Bug 105463] [Feature] Implement pointer events

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from Rick Byers <rbyers at chromium.org>  2012-12-20 07:49:52 PST ---
(In reply to comment #3)
> (From update of attachment 180221 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=180221&action=review
> 
> > WebKit/chromium/public/WebInputEvent.h:135
> > +        // WebPointerEvent
> 
> It's not clear to me that the pointer abstraction should be pushed to the
> platform.  It seems like Chromium is already feeding WebKit information
> about mouse and touch input, and that could just be used to generate
> pointer events within WebKit.  Is there an advantage to synthesizing
> pointer events within Chromium instead?

Yes, talking offline with Scott I suggested he start by trying to synthesize all the pointer events entirely in WebCore.  I think eventually we'd probably want to push it down to the platform, at least on some ports (eg. I think it's the only way to ever add stylus support on Windows - since neither PlatformMouseEvent nor PlatformTouchEvent is really appropriate for that), but I don't think they should worry about that yet.  Scott is in the process of removing all the code in the platform layer now.

Some of the other big outstanding issues in my mind (other than the obvious outstanding debate about whether pointer events should be implemented in WebKit at all) are:

1) How best to avoid duplicating logic that exists already for mouse/touch handling?  I see there's quite a bit of copy/paste of existing code here (mainly in EventHandler.cpp).  In addition to the software engineering issues, you're also going to have to figure out how to get good test coverage of all the added code.   But at this point the patch is just a proof of concept, so not something to worry too much about yet.

2) How will mouse events be suppressed when pointer events are swallowed?  In particular, how do we make sure that all the expected peripheral behavior associated with mouse events occur (and occurs consistently) regardless of whether or not mouse events are generated (and again, ideally without duplicating this code in two places).  I think there's a ton of complexity and opportunity for regressions in subtle but important behavior here.  I'm not sure where on the spectrum to aim between a  major refactoring and cleanup of EventHandler and a lower-risk approach that may duplicate some logic.  One way to shed some light on this is to look through the entire existing set of mouse and touch tests and decide how much of the behavior (and so also tests) needs to exist for pure pointer events.

3) What is the right strategy in general for testing?  Again there's going to be a lot of overlap with the existing tests.  Should we be trying to share some test code (eg. parameterizing some tests so they could run in both mouse and pointer event variants?).

4) What is the right model for touchevents and pointerevents co-existing.  This is primarily a spec issue that will be addressed by the WebEvents working group.  I think we need to allow both types of events to co-exist on the same page (eg. we wouldn't want to restrict librarys / embeddable sites from opting into consuming pointer events out of fear of breaking sites).  The common case is probably easy (along the lines of the mouse event compatibility in the pointer event spec), but it will get tricky when it comes to how mouse events are generated (TE and PE specify a different mapping to mouse events and it' spossible code designed for the TE model could be broken by the PE model in the presence of TouchEvents).

There's also a number of obvious issues of mechanics (probably want a run-time flag to enable this, -webkit prefixes, etc.) but I think we're far from having anything to land so it's not worth worrying about this yet.

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