Clicking on a disabled element

[David Burns]

Today on IRC a discussion was started on what should happen when we click on disabled elements. Currently we will get an error "InvalidElementStateException" when this happens. 

I am of the opinion that clicking on a disabled element should be a NO-OP since we are trying to emulate what a user sees and feels. A user won't get an exception thrown when they click on a disabled element. There was also a view that we should notify the calling code that it tried to use a disabled element.

What are people's thoughts on this?

David

David Burns
URL: http://www.theautomatedtester.co.uk/

[Patrick Lightbody]

I agree with you, though I'm sure I could just as easily be swayed in the other direction :)

--

Patrick Lightbody

+1 (415) 830-5488

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To post to this group, send email to selenium-...@googlegroups.com.
To unsubscribe from this group, send email to selenium-develo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/selenium-developers?hl=en.

[Aditya Ivaturi]

> There was also a
> view that we should notify the calling code that it tried to use a disabled
> element.

Instead of a NO-OP, I'd rather prefer the above to happen. The user
does eventually "realize" that the element is disabled when nothing
happens. So it is visual feedback and translating that to code, I'd
expect some sort of "realization" or "feedback" that the element is
indeed disabled & the click is going to do nothing.

--aditya

[Michael Braiman]

Why not return Boolean value of true if action succeeded

 

[Michael Braiman]

The same apply when you try to sendKeys to disabled textarea.

If action will return true it mean that action succeeded or false which means that action failed because element is disabled or is not supporting this action.

[David Burns]

I would rather have an exception thrown than return a boolean because then its obvious that the action didn't happen then. 

I still prefer a NO-OP since thats what happens in reality.

David Burns
URL: http://www.theautomatedtester.co.uk/

[Ranjan Sakalley]

I agree on an exception being thrown. If I were planning to run a set of steps post the click, I should be told that my plan won't work. (If I my code were to get a boolean from the click and fork, its better to be a bit more clean by checking if the element is enabled or not rather than clicking it first and then inferring). 

Also, I believe in this case, a NOOP should be translated as an exception and not a NOOP as the exception you get when your test fails would not be correct ( would be thrown on subsequent steps ), especially if were not planning on the click happening on a disabled element. 

Thanks,

r.

[Michael Braiman]

There are two method for validation pre and post. In Ajax world pre-validation if element is disabled can succeed but post-validation after or during the action can fail.  You can always wrap your code with pre and post validations with or without exception handling.

 

[Daniel Wagner-Hall]

While I agree that ideologically it shouldn't throw, I think that
pragmatically giving no indication that "something strange happened"
means that 90% of our users will want to replace:

element.click();

with a call to

void selectElement(WebElement element) {
element.click();
if (!element.isSelected()) {
throw ... or fail() or ...;
}
}

unfortunately, 90% of that 90% won't know that this is what they want.
(Also, adding boilerplate)

When we provided such a method, not throwing made a lot more sense
(though IIRC we didn't do so), but now that clicking is the only
interaction we have with WebElements, that feedback is important.

[Simon Stewart]

Time to round off this discussion. The problem is, we're trying to
focus on the user. The question is, which user? The person we're
modeling interacting with the browser? Or the test author?

One option is to consider both cases: having WebElement.click support
the test author and the advanced user interactions support closer
emulation of the user. A second option is to always emulate the user,
and the third option is to make it easier for test authors.

We're going with option 2: it's consistent with our views of almost
emulating the user where possible. Testers who want to verify that
elements are enabled can do so using by firing "element.isEnabled"
first. If we'd gone the other way of always throwing an exception, the
legitimate tests of verifying behavior when clicking on disabled
elements (few though they are) would have been impossible. Option 1 is
just plain ugly (even if it was the one that I originally thought we'd
go for)

All drivers now implement this behavior.

Simon

[Andreas Tolf Tolfsen]

On Tue, 05 Jul 2011 19:11:21 +0200, David Burns
<david...@theautomatedtester.co.uk> wrote:

> Today on IRC a discussion was started on what should happen when we
> click on disabled elements. Currently we will get an error
> "InvalidElementStateException" when this happens.
>
> I am of the opinion that clicking on a disabled element should be a NO-OP
> since we are trying to emulate what a user sees and feels. A user won't
> get an exception thrown when they click on a disabled element. There was
> also a view that we should notify the calling code that it tried to use
> a disabled element.

From a web browser vendor's point of view, we need to be able to click
disabled elements. We are using WebDriver for testing the browser itself,
and it may well happen that there is a bug with the disabled code making
a disabled button behave in an inappropriate way.

Currently we've added a flag in OperaDriver that we switch on for our
internal
tests.

However, on a more general level, I don't think that WebDriver should make
these
kinds of decisions on “logic” for the user. If the user tells WebDriver
to click
something, WebDriver should in my opinion just do so without actually
performing
a check on whether the element is enabled or not first; that's not what I
asked
it to do.

We obviously have to agree on some kind of compromise between convenience
and
just relaying what the user asks us to with no concern whatsoever of what
happens:
WebDriver.navigate().to() is a good example of this.

In the case of clicking a disabled element, however, the user might wish
to check
that clicking a disabled button doesn't actually trigger an event.

[Andreas Tolf Tolfsen]

On Thu, 07 Jul 2011 12:39:58 +0200, Simon Stewart
<simon.m...@gmail.com> wrote:

> Time to round off this discussion. The problem is, we're trying to
> focus on the user. The question is, which user? The person we're
> modeling interacting with the browser? Or the test author?
>
> One option is to consider both cases: having WebElement.click support
> the test author and the advanced user interactions support closer
> emulation of the user. A second option is to always emulate the user,
> and the third option is to make it easier for test authors.
>
> We're going with option 2: it's consistent with our views of almost
> emulating the user where possible.

Question: How is not allowing the user to click a disabled button
emulating user behaviour? A user _will_ (and more importantly _can_)
click disabled elements. Why won't WebDriver do this for me when I tell
it to?

> Testers who want to verify that elements are enabled can do so using
> by firing "element.isEnabled" first.

That is probably fine in the 90% case. In the case of actual emulation
(i.e. testing a web browser) we want to make sure that no bad stuff happens
if you did indeed happen to press the disabled button.

Things to consider: What would happen if there is a JavaScript event tied
to the disabled button overriding its disabledness qualities? What if the
browser has a bug that crashes or triggers an error if you click the
disabled
button?

[Simon Stewart]

On Thu, Jul 7, 2011 at 11:56 AM, Andreas Tolf Tolfsen
<andr...@opera.com> wrote:
> On Thu, 07 Jul 2011 12:39:58 +0200, Simon Stewart
> <simon.m...@gmail.com> wrote:
>
>> Time to round off this discussion. The problem is, we're trying to
>> focus on the user. The question is, which user? The person we're
>> modeling interacting with the browser? Or the test author?
>>
>> One option is to consider both cases: having WebElement.click support
>> the test author and the advanced user interactions support closer
>> emulation of the user. A second option is to always emulate the user,
>> and the third option is to make it easier for test authors.
>>
>> We're going with option 2: it's consistent with our views of almost
>> emulating the user where possible.
>
> Question: How is not allowing the user to click a disabled button
> emulating user behaviour?  A user _will_ (and more importantly _can_)
> click disabled elements.  Why won't WebDriver do this for me when I tell
> it to?

Option 2 was to be consistent with the user: we allow clicks on
disabled elements. Option 3 (making it easy for test authors) would
have meant not allowing clicks on disabled elements.

>> Testers who want to verify that elements are enabled can do so using
>> by firing "element.isEnabled" first.
>
> That is probably fine in the 90% case.  In the case of actual emulation
> (i.e. testing a web browser) we want to make sure that no bad stuff happens
> if you did indeed happen to press the disabled button.
>
> Things to consider:  What would happen if there is a JavaScript event tied
> to the disabled button overriding its disabledness qualities?  What if the
> browser has a bug that crashes or triggers an error if you click the
> disabled
> button?

And that's exactly the sort of reasoning that means that lead us to
make the choice we did :)

Simon

[Tim Taylor]

Andreas represents my concerns exactly. I go further and object to the
idea that Selenium can know what is and isn't clickable. A click on a
disabled element will bubble up the DOM to other potential click
handlers. Depending on the design of the app a click may represent a
legitimate user action. Neither a NO-OP nor throwing an exception are
reasonable behaviors of the API.

On Jul 7, 6:56 am, "Andreas Tolf Tolfsen" <andrea...@opera.com> wrote:
> On Thu, 07 Jul 2011 12:39:58 +0200, Simon Stewart  
>

[Simon Stewart]

Sure. And as I said to Andreas, we're allowing clicks on disabled
elements. "no-op" in this case basically meant "the element won't
change state via a direct call to element.selected, and an exception
won't be thrown". You'll see click handlers firing.

Simon

[Simon Stewart]

As an aside, I really should learn how to express myself more clearly :)

Simon

[Tim Taylor]

If DOM click events are always generated, referring to that as "no-op"
behavior (as the API docs currently do) confuses me greatly.

[Simon Stewart]

Which is why I need to get better at explaining what I mean :)

Simon

[Andreas Tolf Tolfsen]

* Also sprach Tim Taylor <t...@tool-man.org>:

> If DOM click events are always generated, referring to that as "no-op"
> behavior (as the API docs currently do) confuses me greatly.

This is a good point, that's what caused my initial confusion reading
Dave's replies.

[Andreas Tolf Tolfsen]

* Also sprach Simon Stewart <simon.m...@gmail.com>:

> On Thu, Jul 7, 2011 at 11:56 AM, Andreas Tolf Tolfsen <andr...@opera.com> wrote:
> > On Thu, 07 Jul 2011 12:39:58 +0200, Simon Stewart <simon.m...@gmail.com> wrote:
> >
> >> One option is to consider both cases: having WebElement.click support
> >> the test author and the advanced user interactions support closer
> >> emulation of the user. A second option is to always emulate the user,
> >> and the third option is to make it easier for test authors.
> >>
> >> We're going with option 2: it's consistent with our views of almost
> >> emulating the user where possible.
> >
> > Question: How is not allowing the user to click a disabled button
> > emulating user behaviour? �A user _will_ (and more importantly _can_)
> > click disabled elements. �Why won't WebDriver do this for me when I tell
> > it to?
>
> Option 2 was to be consistent with the user: we allow clicks on
> disabled elements. Option 3 (making it easy for test authors) would
> have meant not allowing clicks on disabled elements.

Thanks for clarifying this, I must have misunderstood your first post.
(-:

[David Burns]

That's my fault. When I put NOOP I should have said that it should act _essentially_ like a NOOP because throwing an exception isn't what people would expect.

David