Re: Spec Feedback - general stuff

Hi John,

Thanks for the email. Answers inline.

On Tue, Oct 29, 2013 at 6:00 PM, John Jansen <>wrote:

> This is just some general question/feedback. Let me know if it would be
> better in separate emails...

I'm happy to get feedback in any format :) As long as inline replies are
okay, I think it's manageable to put everything into a single email.

> Thanks guys!
> Navigation is not really been called out the way users navigate the web.
> * Back
> * Forward
> * Refresh

There's are in the JSON wire protocol of the selenium project. Adding them
to the spec is a good idea, and I've made a note to do so.

> Mouse/ Keyboard input
> * Hover (css :hover as well as the various javascript mouse events
> including nested menus). Is this for

Hover would be implemented by moving the mouse to the location of an
element, rather than explicitly handled as a separate command. Once we
flesh out 14 this may be clearer.

> * Web app controls are not called out. For example, custom context menus
> as well as the following functions:
> o Right click
> o Double click
> o Scroll in/ out
> o Autoscroll
> o Click and drag
> o Pinch

These are what the selenium project refers to as "Advanced User
Interactions" (as opposed to the simple interactions offered from
WebElement) It's something we wrestled with a lot: we like keeping the
surface area of the API as small as possible, but having said that, there's
a need for the ability to express rich interactions from multiple devices.
A laptop with a touchscreen and a separate pen input device (like a Wacom
tablet) is the pathological case, but things like tablets are already
making things interesting.

I believe that these are handled by a combination of section 14 and
Mozilla's proposal for simulating multiple simultaneous inputs, which you
may remember from the last face to face.

Those raw commands are obviously pretty opaque to users, which is why most
of the existing webdriver bindings offer something similar to<>
use the java bindings as an example, since they're the ones I'm most
familiar with)

Out of curiosity, what is "autoscroll" in this case? I'm not familiar with
the term.

> "Keyboard input from the physical keyboard should be ignored"
> * Does this mean the physical mouse should be ignored as well?

Yes. Noted, and I'll add it to the spec. Good catch :)

> Send keys to page itself, rather than webelements...

Handled by sending those keyboard inputs to the BODY element.
Alternatively, using the "Actions" class above gives you a mechanism to use
that sends keyboard input to the current active element (as defined by HTML

> * Backspace for back
> * Spacebar to scroll
> * Tab to select elements

If input events are implemented correctly, these should "just work".
Certainly, I've done accessibility testing with firefox on Windows before
by tabbing through the various fields of a page. It one of the reasons that
exists. I've also seen backspace work for "back" in one particularly
painful debugging session.

> Capabilities
> * Support for extensions

I'm not entirely sure what you mean. Are you suggesting we extend section
18 to also cover extensions by vendors? If so, that's a great idea.

> Detecting form state
> * Checkbox and radio button IWebElements should be able to return their
> checked state

This is covered in section 10.2. We refer to the property as "selected",
but the definition of "selectable" is:

"A selectable element is either an OPTION element or an INPUT element of
type "checkbox" or "radio"."

> * Radio button groups should be able to return which button (if any) is
> checked

I do this by iterating over the elements in the button group until I find
the button which is selected. Does that approach not work for you?



Received on Sunday, 3 November 2013 20:10:35 UTC