Bug 98007 - A Spin button should release mouse event capturing when a modal dialog opens
Summary: A Spin button should release mouse event capturing when a modal dialog opens
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Kent Tamura
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-01 02:52 PDT by Kent Tamura
Modified: 2012-11-15 20:30 PST (History)
5 users (show)

See Also:


Attachments
Patch (8.53 KB, patch)
2012-10-01 21:39 PDT, Kent Tamura
no flags Details | Formatted Diff | Diff
WIP (15.67 KB, patch)
2012-11-07 00:02 PST, Kent Tamura
no flags Details | Formatted Diff | Diff
Patch 2 (30.39 KB, patch)
2012-11-13 21:01 PST, Kent Tamura
no flags Details | Formatted Diff | Diff
Patch 3 (22.29 KB, patch)
2012-11-13 23:55 PST, Kent Tamura
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kent Tamura 2012-10-01 02:52:57 PDT
http://code.google.com/p/chromium/issues/detail?id=145489

If a web page opens alert() or something in a 'change' event handler of input[type=number] and a user press the spin button in it, a modal dialog opens but mouse events are still captured by the spin button. We should release mouse event capturing in such case.
Comment 1 Kent Tamura 2012-10-01 21:39:53 PDT
Created attachment 166602 [details]
Patch
Comment 2 Hajime Morrita 2012-10-01 23:42:36 PDT
Comment on attachment 166602 [details]
Patch

Is this frame local?

We could add a listener/observer on Chrome object for detecting willOpenMocalDialog(),
and let SpinButtonElement to implement that listener and register itself to Chrome object.
Adding a virtual method to Node only for this purpose looks a bit too abusive for me.
Comment 3 Darin Adler 2012-10-02 09:56:02 PDT
Comment on attachment 166602 [details]
Patch

I don’t like the assumptions here. Not all clients will use modal dialogs for things like a JavaScript alert. And many clients will use modal dialogs in other situations, like for a file chooser in an input element. It would be better if we did not have to hardcode the assumption that a modal dialog will come up, but could instead respond to the fact that one did come up.
Comment 4 Hajime Morrita 2012-10-02 22:07:22 PDT
(In reply to comment #3)
> (From update of attachment 166602 [details])
> I don’t like the assumptions here. Not all clients will use modal dialogs for things like a JavaScript alert. And many clients will use modal dialogs in other situations, like for a file chooser in an input element. It would be better if we did not have to hardcode the assumption that a modal dialog will come up, but could instead respond to the fact that one did come up.

Yeah, that is my point. If Chrome object can notify the fact, 
then native implementation which uses mousemove can register itself to
handle modal dialogs regardless who does it.
Comment 5 Kent Tamura 2012-10-10 00:16:07 PDT
Comment on attachment 166602 [details]
Patch

Yeah, we need a generalized fix.

http://code.google.com/p/chromium/issues/detail?id=154329 ':hover isn't cleared for alert() or confirm()' is a similar problem.
Comment 6 Kent Tamura 2012-11-07 00:02:09 PST
Created attachment 172727 [details]
WIP
Comment 7 Kent Tamura 2012-11-07 00:18:41 PST
(In reply to comment #6)
> Created an attachment (id=172727) [details]
> WIP

I still need to add a function to Node in this new patch because EventHandler assumes m_capturingMouseEventsNode is Node.

> could instead respond to the fact that one did come up.

IMO, it's ok to cancel capturing on any events which *might* open dialogs/popups.
Comment 8 Kent Tamura 2012-11-13 21:01:47 PST
Created attachment 174066 [details]
Patch 2
Comment 9 Hajime Morrita 2012-11-13 21:38:05 PST
CC-ing haraken.
This addition might increase sizeof(Node) but I'm sure if it really does. 
Haraken, do you remember the bottom line of past discussion?
Comment 10 Kentaro Hara 2012-11-13 21:43:54 PST
Comment on attachment 174066 [details]
Patch 2

View in context: https://bugs.webkit.org/attachment.cgi?id=174066&action=review

> Source/WebCore/dom/Node.h:125
> +class Node : public EventTarget, public ScriptWrappable, public TreeShared<Node, ContainerNode>, public PopupOpeningObserver {

Yeah, this will increase sizeof(Node) by 8 byte, which wouldn't be acceptable.

A virtual function table pointer is needed for each multiply-inherited class that has virtual functions. Currently only EventTarget has virtual functions and thus each Node has only one virtual function table pointer. If you add PopupOpeningObserver, which has virtual functions, it will add one more virtual function table pointer to each Node.
Comment 11 Kent Tamura 2012-11-13 21:50:56 PST
Comment on attachment 174066 [details]
Patch 2

View in context: https://bugs.webkit.org/attachment.cgi?id=174066&action=review

>> Source/WebCore/dom/Node.h:125
>> +class Node : public EventTarget, public ScriptWrappable, public TreeShared<Node, ContainerNode>, public PopupOpeningObserver {
> 
> Yeah, this will increase sizeof(Node) by 8 byte, which wouldn't be acceptable.
> 
> A virtual function table pointer is needed for each multiply-inherited class that has virtual functions. Currently only EventTarget has virtual functions and thus each Node has only one virtual function table pointer. If you add PopupOpeningObserver, which has virtual functions, it will add one more virtual function table pointer to each Node.

I see.  I'll update the patch so that I don't change Node parents.
Comment 12 Kent Tamura 2012-11-13 23:55:18 PST
Created attachment 174088 [details]
Patch 3

Node doesn't inherit PopupOpeningObserver
Comment 13 Hajime Morrita 2012-11-14 19:45:41 PST
Comment on attachment 174088 [details]
Patch 3

This version is much better than before!
Comment 14 WebKit Review Bot 2012-11-15 20:30:42 PST
Comment on attachment 174088 [details]
Patch 3

Clearing flags on attachment: 174088

Committed r134886: <http://trac.webkit.org/changeset/134886>
Comment 15 WebKit Review Bot 2012-11-15 20:30:46 PST
All reviewed patches have been landed.  Closing bug.