Bug 12326 - Changes to mouse events to make them work with windows native widgets
Summary: Changes to mouse events to make them work with windows native widgets
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 420+
Hardware: PC OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-18 14:50 PST by Michelle Bell
Modified: 2007-03-12 06:29 PDT (History)
0 users

See Also:


Attachments
Patch for passing mouse events to windows widgets. (6.34 KB, patch)
2007-01-18 14:54 PST, Michelle Bell
mjs: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michelle Bell 2007-01-18 14:50:46 PST
In the windows port, we are using some instances of native widgets, and we'd like mouse events to be able to pass through the EventHandler into the appropriate widget.  There is some plumbing for this already for the mouse-down event, but not for other events.  There appears to be some confusion around whether this is for a traditional windows-style SetCapture() or something else.

Without an equivalent NSView, I see no way to get mouse events to widgets other than to pass all 3 mouse event types (mouse-down, mouse-release, mouse-move) to the widgets.  Capturing still needs to be done, albeit a separate issue from this bug.

This patch just plumbs these and adds a couple of stubs for the mac version in a benign way.  Also store the native mouse event information (hwnd, msg, wparam, and lparam) into the PlatformMouseEvent.h so that we don't convert back and forth obsessively.

There is a chance I'm not understanding the underlying design for windows; if so, let me know.  But after looking at the code, it appears that the windows version doesn't quite work yet, and this simple patch is a reasonable way to fix it.  Advice welcome!
Comment 1 Michelle Bell 2007-01-18 14:54:02 PST
Created attachment 12544 [details]
Patch for passing mouse events to windows widgets.
Comment 2 Maciej Stachowiak 2007-01-22 23:17:19 PST
I don't think this is needed, because the plan for windows is to use all engine-rendered and operated form controls, as for Mac. Which form controls need native widgets (by this I assume you mean an HWND)?  It's hard to evaluate this code without knowing what is going to make use of it.
Comment 3 Maciej Stachowiak 2007-01-22 23:49:37 PST
Comment on attachment 12544 [details]
Patch for passing mouse events to windows widgets.

I checked with someone who knows more about the windows form controls and this patch definitely seems wrong. r-. But maybe there's some reason for this that I am not getting.
Comment 4 Michelle Bell 2007-01-25 15:12:05 PST
OK -

The reason for the native widgets is because I'm working on getting Flash to work as an NPAPI plugin.  The NPAPI spec has "windowed" and "windowless" widgets.  For windowed widgets, you need to hand the plugin a native HWND and let it work.  For windowless, you need to pass the mouse events manually to the plugin.

If this is the wrong way to pass events - what is the right way to pass them?  
Comment 5 Michelle Bell 2007-03-12 06:29:07 PDT
Since I picked up later revisions of webkit, I see the Widget::handleEvent method is the right way to do this.