[Webkit-unassigned] [Bug 174710] WebDriver: handle click events on option elements

[bugzilla-daemon at webkit.org]

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

--- Comment #9 from Carlos Garcia Campos <cgarcia at igalia.com> ---
Comment on attachment 317573
  --> https://bugs.webkit.org/attachment.cgi?id=317573
Try to fix mac builds

View in context: https://bugs.webkit.org/attachment.cgi?id=317573&action=review

>> Source/WebKit/UIProcess/Automation/Automation.json:430
>> +                { "name": "isOptionElement", "type": "boolean", "description": "If the element is an HTML option element" }
> 
> The driver should just use a small JS snippet to do this, unless I'm missing something. Unlike the other out-parameters, this can be easily computed using client JS. There are cases where safaridriver does this, for example to see if an <input> is type=file and whether it has "multiple" attribute or not. I don't want to extend the protocol every time we need to do a type test on an element. Reducing message traffic by one message is not important since the REST service and browser are using fast message passing (hopefully). On macOS, our async XPC is basically free.

I didn't do this for efficiency, but just for convenience :-) the code in the driver side is a lot simpler.

>> Source/WebKit/UIProcess/Automation/Automation.json:435
>> +            "name": "selectOptionElement",
> 
> This seems fine, but maybe call it toggleOptionElement?

It only toggles when the select is multiple, otherwise it selects the element (in case of combo element).

>> Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.cpp:613
>> +    String elementNotInteractableErrorType = Inspector::Protocol::AutomationHelpers::getEnumConstantValue(Inspector::Protocol::Automation::ErrorMessage::ElementNotInteractable);
> 
> This seems like the right thing to do, but I can't find it in the spec. Should I file bug?

The spec says we should do the select algorithm only for option elements not for optgroup ones, so in theory we should do the normal click for group options, but I don't think it makes sense. First, it won't have any effect if we manage to click it, but it's not easy to clikc it anyway, it could be hidden in the drop down list or off the list box scroll area. So, yes, I think the spec should mention what to do with optgroups.

>> Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.cpp:626
>> +    if (selectElement->isDisabledFormControl() || optionElement.isDisabledFormControl()) {
> 
> Ditto.

Same here, the spec doesn't say anything, element not selectable error is only mentioned in the errors table. I had to add this to fix a couple of selenium test.

>> Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.cpp:632
>> +    selectElement->optionSelectedByUser(optionElement.index(), true, selectElement->multiple());
> 
> This won't fire mouseover/move/down/up/click events like the spec wants. We'll probably have to simulate those events ourselves as the only way to do it natively would be to try and click the native widgets. I think that would be problematic for dropdown menus as the interaction is a bit more subtle than the DOM events would lead you to believe.

I know, even when it's in the spec I don't think selenium will expect we fire all those events, at least we fire the important ones also mentioned in the spec, the input and change events. I'll add a FIXME about the other events, but I wouldn't block this feature on those.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170809/fe5fbf48/attachment-0001.html>