[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