[Webkit-unassigned] [Bug 60563] [Chromium]Click event is not fired for a menulist <select>

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=60563


Naoki Takano <takano.naoki at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dglazkov at google.com




--- Comment #19 from Naoki Takano <takano.naoki at gmail.com>  2011-05-14 21:02:55 PST ---
After looking around the source code, I guess render_view in Chromium code is better choice to forward mouse up event.

But I'm stuck I cannot forward the event well.

Dimitri,
Are you familiar with render_view message routing in Chromium?

Or do you know who is the right person to ask?

Thanks,

(In reply to comment #18)
> Thank you for your review so many times!!
> I appreciate your review even if so many round trips;-)
> Now I understand more clearly what you are talking about.
> 
> AFAIK, in chromium, we use PopupMenuChromium.cpp to handle events.
> But it doesn't know the parent window. That's why I forward the event to WebCore.
> 
> On the other hand, PopupMenuWin.cpp and WebKit2 have there parent window handles.
> That's why they can simulate the mouse click natively.
> 
> So I guess, if we cannot touch WebCore part, we should also have to have parent handle in PopupMenuChromium.cpp. Of course the handle should be Chromium specific handle, not native HWND or GTK handles.
> 
> But still I'm still not sure how we can simulate mouse event between Chromium and WebKit.
> 
> 
> >Kent-san,
> 
> Do you have any idea about that, if you know?
> 
> Thanks,
> 
> 
> 
> (In reply to comment #16)
> > (In reply to comment #15)
> > > Created an attachment (id=93407)
 --> (https://bugs.webkit.org/attachment.cgi?id=93407&action=review) [details] [details] [details]
> > > EventHandler version
> > > 
> > > According to your suggestion, I changed to use EventHandler to forward the event.
> > > 
> > > Actually, just forwarding doesn't work well because of coordinate issue.
> > > 
> > > As you know, user click the item in select option window, the mouse point is out of bound from the actual select widget.
> > > The event hander isn't fired correctly.
> > > 
> > > So, inspired by WebKit2 solution, I stored the mouse button down position first, and use the location when the up.
> > > 
> > > I left dispatchMouseUpAndClick() in AutoFillPopupMenuClient.h, because I didn't get your answer.
> > > 
> > > Please review again.
> > > 
> > > Thanks,
> > 
> > This patch looks even worse than the others :(
> > 
> > I am sorry that this is taking so many roundtrips. I don't know the code around popups well enough to offer the solution directly, but I can see a problem with existing code. In short, it's:
> > 
> > Don't reach into WebCore to make stuff in WebKit layer work. 
> > 
> > The long version: See how the patch in bug 57904 doesn't make any changes in WebCore code?  That's because they respect the layering boundaries and realize that even though it is more work to fix this particular issue, the WebCore code should work the same way for _all_ ports. What you're proposing is hooks in WebCore that are only relevant for Chromium. I assert that this is unnecessary.
> > 
> > I actually rather like the solution in bug 57904 and find it very rational. Co-opting the mousedown event seems reasonable and logical from the perspective of WebCore.
> > 
> > Hope this helps.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.