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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri May 27 09:32:27 PDT 2011


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





--- Comment #44 from Jay Civelli <jcivelli at chromium.org>  2011-05-27 09:32:27 PST ---
(From update of attachment 95112)
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.



More information about the webkit-unassigned mailing list