RESOLVED FIXED 98007
A Spin button should release mouse event capturing when a modal dialog opens
https://bugs.webkit.org/show_bug.cgi?id=98007
Summary A Spin button should release mouse event capturing when a modal dialog opens
Kent Tamura
Reported 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.
Attachments
Patch (8.53 KB, patch)
2012-10-01 21:39 PDT, Kent Tamura
no flags
WIP (15.67 KB, patch)
2012-11-07 00:02 PST, Kent Tamura
no flags
Patch 2 (30.39 KB, patch)
2012-11-13 21:01 PST, Kent Tamura
no flags
Patch 3 (22.29 KB, patch)
2012-11-13 23:55 PST, Kent Tamura
no flags
Kent Tamura
Comment 1 2012-10-01 21:39:53 PDT
Hajime Morrita
Comment 2 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.
Darin Adler
Comment 3 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.
Hajime Morrita
Comment 4 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.
Kent Tamura
Comment 5 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.
Kent Tamura
Comment 6 2012-11-07 00:02:09 PST
Kent Tamura
Comment 7 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.
Kent Tamura
Comment 8 2012-11-13 21:01:47 PST
Hajime Morrita
Comment 9 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?
Kentaro Hara
Comment 10 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.
Kent Tamura
Comment 11 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.
Kent Tamura
Comment 12 2012-11-13 23:55:18 PST
Created attachment 174088 [details] Patch 3 Node doesn't inherit PopupOpeningObserver
Hajime Morrita
Comment 13 2012-11-14 19:45:41 PST
Comment on attachment 174088 [details] Patch 3 This version is much better than before!
WebKit Review Bot
Comment 14 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>
WebKit Review Bot
Comment 15 2012-11-15 20:30:46 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.