Bug 105463

(From update of attachment 180221 [details])
Thanks for contributing a patch.

If you wanted reviewers to take a look at your patch, please set r?. If you don’t want them to review your patch, then don’t set any flag on r (like I just removed it now). r- indicates that a reviewer had already taken a look at your patch and decided that it should be rejected, which I believe isn’t the case.

Sorry, that was my suggestion since they know this patch is nowhere near ready to be reviewed (lots of work left, lots of testing to be done, etc.).  I know there's been debate over explicitly marking review- on webkit-dev, maybe I misinterpreted the consensus.

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

I'm not sure I understand the {Got,Lost}PointerCapture events.

(In reply to comment #2)
> Sorry, that was my suggestion since they know this patch is nowhere near ready to be reviewed (lots of work left, lots of testing to be done, etc.).  I know there's been debate over explicitly marking review- on webkit-dev, maybe I misinterpreted the consensus.

I think the problem is that we don't have a flag for saying "Please give me initial comments on my work-in-progress patch"

(In reply to comment #3)
> (From update of attachment 180221 [details] [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.

Besides the issues of mechanics, it seems to me there was not consensus to add this feature to WebKit when it was proposed on webkit-dev. Out of courtesy I won't mark the bug as WONTFIX (as perhaps a patch or spec revisions would change people's minds). But please make sure not to r+ or land anything until/unless the state of the feature proposal discussion changes.

(In reply to comment #6)
> But please make sure not to r+ or land anything until/unless the state of the feature proposal discussion changes.

Maybe we need a keyword of some sort like PendingWebKitDevResolution?