Bug 13298 – Widget needs a virtual method to be notified of mouse capture changes

• Status: UNCONFIRMED
• Component: Platform

[Matt Perry]

On Windows, mouse capture can be changed externally from the application.  In these situations, the porting layer needs to notify the widget that it's capture has changed, in a way that can be handled differently for different widgets.

Patch coming.

[Matt Perry]

Created attachment 13982 [details]
add captureChanged virtual method

[Dave Hyatt]

Comment on attachment 13982 [details]
add captureChanged virtual method

I do not understand why this is necessary.

[Dave Hyatt]

See checkin for bug  13274.  I eliminated the notion of Widget-level capture.

[Dave Hyatt]

If this was for scrollbar, as part of 13274 I made EventHandler smart enough to handle scrollbar capture too.

[Matt Perry]

Sorry, I hadn't updated to the latest revision.  I see that the Windows-specific capture methods are now gone.

However, I think we still need a way to notify WebCore (maybe the EventHandler, or the capturing widget itself?) that capture has been removed.  It will not always happen on mouse-up.  On Windows, if a window has capture, and (for example) you press Alt+Tab, capture is removed and a WM_CANCELMODE message is sent to that window.  Widgets will need to be notified of this.

[Dave Hyatt]

I think my preference would be to synthesize a mouse up event and send it in to WebCore when that happens.

[Dave Hyatt]

Is Alt+Tab the only example?  It seems pretty unlikely that a user would hit those keys while holding down the mouse. :)

[Matt Perry]

I think capture can be stolen in other cases as well.  Perhaps if a new window pops up and takes focus.

A mouse-up event seems reasonable, as long as it's unlikely to interfere with pages that watch for mouse-up javascript events.

[David Kilzer (:ddkilzer)]

Reopening bug as discussion is ongoing.

[Dave Hyatt]

The reason I say do a mouse up is that a page that is using JS events to do its own "capturing" sort of behavior would also get stuck if it doesn't get the up.

[Oliver Hunt]

We'd need to be careful when synthesizing the mouse up event, eg. take the case where a weebpage uses js to implement buttons manually (because we all want to do that), if we send a mouse up when we lose focus it could be interpreted as a "click" and then badness could ensue.

[Dave Hyatt]

Lowering priority, since none of these cases are critical.