[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
----------------------------------------------------------------------------
            Summary|[Chromium]Click event is    |[Chromium] Click event is
                   |not fired for a menulist    |not fired for a menulist
                   |<select>                    |<select>




--- Comment #46 from Naoki Takano <takano.naoki at gmail.com>  2011-05-30 18:26:05 PST ---
Jay,

Thank you for your detail suggestion for the test.

Now I can find how I write unit test.

But this looks like only for Win, and my dev environment is Linux;-(

Actually I have Win7 VMWare environment, so I try to implement it on it. It is really slow though;-(

If I have chance, I want to port this Popup window unit test for Linux. But this is another topic...

Thanks,

(In reply to comment #44)
> (From update of attachment 95112 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=95112&action=review
> 
> > Source/WebCore/manual-tests/select-element-mouse-event.html:12
> > +<select id=s size=1>
> 
> I can think of several other important test cases:
> - have disabled items in the select and try to click it
> - have a onchange event handler that removes the select node from the DOM (we had crashes in the past with such scenarios)
> - have a onclick event handler that removes the select node from the DOM
> - use the keyboard to make the selection and ensures the right events are sent (change but no click)
> 
> Regarding making unit-tests. 
> You can load actual content in a WebView from a test. See for example WebFrameTest and WebPageSerializerTest.
> These tests use mocking of URLs, but in your case you could probably just get away with a data URL for the main frame content.
> I cannot guarantee this is going to work, but I think it would be a good thing to try as having unit-tests for this would be really nice.
> 
> > Source/WebCore/platform/chromium/PopupMenuChromium.cpp:685
> > +    m_focusedNode = 0;
> 
> In the case where acceptIndex returned false, don't we want to keep the m_focusedNode? (the popup might not have been hidden)
> 
> > Source/WebCore/platform/chromium/PopupMenuChromium.cpp:1111
> > +    return true;
> 
> Don't you want to return false in that case?

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