WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
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
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Kent Tamura
Comment 1
2012-10-01 21:39:53 PDT
Created
attachment 166602
[details]
Patch
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
Created
attachment 172727
[details]
WIP
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
Created
attachment 174066
[details]
Patch 2
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.
Top of Page
Format For Printing
XML
Clone This Bug