Propose API Change - driver.switchTo().activeElement() to driver.findElement(By.active())

[David Burns]

Hey All,

I would like to propose a method name change.

Currently to get the active element on the page we need to do

driver.switchTo().activeElement()

which is not exactly what we are doing. We aren't switching to anything. We are just doing a find element so would like to change to

driver.findElement(By.active())


I would like to get your thoughts on this!

David

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

[Ken Kania]

That makes more sense to me (although still a little bit weird).  What about driver.getActiveElement()?  You don't want to do this because it's adding another method to the main interface?

Ken

--
 
 

[David Burns]

I actually suggested that first but there were objections in IRC.

I agree that getActiveElement is more intuitive so happy to go with that one.

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

--
 
 

[Bill Ross]

I agree that getActiveElement is more intuitive.

Speaking of activity, is active status assigned to an element if
it is inspected? Presumably not in the case of a hypothetical
getAttribute("active").

Bill

> --
>
>

[Jason Leyba]

+1 for getActiveElement.

On Fri, Jan 11, 2013 at 7:25 PM, Bill Ross <ro...@cgl.ucsf.edu> wrote:

I agree that getActiveElement is more intuitive.

Speaking of activity, is active status assigned to an element if
it is inspected? Presumably not in the case of a hypothetical
getAttribute("active").

This is the element that currently has focus.  I believe all drivers have it implemented as "document.activeElement || document.body".

--

[Jim Evans]

As I did on IRC, I will add my +1 for getActiveElement.

[Simon Stewart]

Active element:

http://www.w3.org/TR/html5/editing.html#dom-document-activeelement

Simon

--

[Simon Stewart]

-1 for "getActiveElement"

~1 for driver.findElement(By.active())

Rationale: The main WebDriver and WebElement interfaces already have a clearly defined mechanism for finding elements: findElement. Adding an additional API for doing is redundant. Adding a new By is at least consistent with the way that we already do things. 

Simon

--
 
 

[Simon Stewart]

Proposed change:

* Delete the "active element" logic entirely.

Rationale: it's totally redundant and only has one particular use-case (that of testing that tabindex in forms follows something sane. The use case of "I don't know what element will be focused" is bogus as it implies that the tester has no understanding of their app: they have deeper problems). 

We had it initially because old versions of firefox and safari didn't implement "document.activeElement" All supported browsers do now.

Simon

[Adam Goucher]

On 2013-01-15 6:38 AM, Simon Stewart wrote:
> Proposed change:
>
> * Delete the "active element" logic entirely.
>
> Rationale: it's totally redundant and only has one particular use-case
> (that of testing that tabindex in forms follows something sane. The
> use case of "I don't know what element will be focused" is bogus as it
> implies that the tester has no understanding of their app: they have
> deeper problems).
>
> We had it initially because old versions of firefox and safari didn't
> implement "document.activeElement" All supported browsers do now.

So just to be clear for sake of mail archives and such, by removing all
notion of active element from webdriver, if one really wanted the active
element they would need to do something like this?

e = driver.execute_script('return document.activeElement;')

-adam

[Simon Stewart]

That would be it. I've only been given one valid use case for this method, and it's the one I mentioned in my email. 

Simon

-adam

--

[Luke Inman-Semerau]

Isn't another use case:

Ensure certain element has focus on page load?

But yeah, personally I don't care as I've never needed to use this. 

-Luke

--
 
 

[Ivan De Marino]

I like

    driver.findElement(By.active())

over

    driver.getActiveElement()

for the same reasons Simon was highlighting.

I'm against getting rid of it because, despite having never used it, I can see someone interested in using it.

And throwing away a call, asking developers to "use JavaScript evaluation", it's a bit harsh.

Ivan

[Jason Leyba]

Yes, fetching the "active element" appears to be a limited use case, but it's not just tab order. For instance, you might want to verify a specific field is focused upon opening a dialog.

As for doing things through JS, I'm a little surprised how often "just use executeScript" is coming up lately.  Feels too similar to doing everything through Selenium.getEval...

--
 
 

[Simon Stewart]

I'm trying to keep the surface area of the API exploding. A "add a method" here and a "we need to do this" there, and we'll end up with a bloaty horror. We've avoided that so far by adopting a "default no" stance to API additions and attempting to get some consistency. If we're focusing on what to do with "active element", my guiding light is that any change we make should lead to greater consistency of the API. Removing the method entirely reduces the API size (which I like) and moving to findElement(By.active()) increases consistency. Both are good. Adding a new method to the core WebDriver interface is not good.

It's a shame that there isn't a consistent attribute or property that we could look at ("hasFocus()" is a function and doesn't appear to be implemented in chrome). Otherwise I'd be suggesting "By.attribute(name, expectedValue)" with the same semantics as WebElement.getAttribute()

Simon

--
 
 

[Daniel Wagner-Hall]

I think we should keep the method.  I know people doing accessibility testing for whom "what is currently focused" is significant.

I think the SearchContext interface could reasonably have a getActiveElement() method.

--
 
 

[Simon Stewart]

Adding to the SearchContext adds an additional method to WebElement and WebDriver, expanding the API. That's vaguely amusing after my last email :) I'm leaning more and more to adding the new By or just leaving things as they are.

Simon

--
 
 

[Bill Ross]

Speaking of additions, how about a WebElement.getParent() method? Or
in keeping with this thread, WebElement.findElement(By.parent())?

I have a case where sometimes (~1-10%) webdriver sees an element as
invisible even though it is visible on the screen, and it has been
suggested (thanks Darrell) that something somewhere up the DOM might
have a bad attribute that causes it. So I'd like to walk back up the
DOM, dumping attributes at each step, to compare a case where the
element is 'invisible' with one where it isn't. What do you think?

Speaking of invisibility, what if ElementNotVisibleException somehow
explained what was causing the status? (0 size, etc)

Thanks,
Bill

Simon Stewart <simon.m...@gmail.com> wrote:

> I'm trying to keep the surface area of the API exploding. A "add a method"
> here and a "we need to do this" there, and we'll end up with a bloaty
> horror. We've avoided that so far by adopting a "default no" stance to API
> additions and attempting to get some consistency. If we're focusing on what
> to do with "active element", my guiding light is that any change we make
> should lead to greater consistency of the API. Removing the method entirely
> reduces the API size (which I like) and moving to findElement(By.active())
> increases consistency. Both are good. Adding a new method to the core
> WebDriver interface is not good.
>
> It's a shame that there isn't a consistent attribute or property that we
> could look at ("hasFocus()" is a function and doesn't appear to be
> implemented in chrome). Otherwise I'd be suggesting "By.attribute(name,
> expectedValue)" with the same semantics as WebElement.getAttribute()
>
> Simon
>
> On Wed, Jan 16, 2013 at 12:10 AM, Jason Leyba <jml...@gmail.com> wrote:
>
> > Yes, fetching the "active element" appears to be a limited use case, but
> > it's not just tab order. For instance, you might want to verify a specific
> > field is focused upon opening a dialog.
> >
> > As for doing things through JS, I'm a little surprised how often "just use
> > executeScript" is coming up lately. Feels too similar to doing everything
> > through Selenium.getEval...
> >
> >
> > On Tue, Jan 15, 2013 at 10:00 AM, Ivan De Marino <detron...@gmail.com>wrote:
> >
> >> I like
> >>

> >> driver.findElement(By.active()**)

> >>
> >> over
> >>
> >> driver.getActiveElement()
> >>
> >> for the same reasons Simon was highlighting.
> >>
> >> I'm against getting rid of it because, despite having never used it, I
> >> can see someone interested in using it.
> >> And throwing away a call, asking developers to "use JavaScript
> >> evaluation", it's a bit harsh.
> >>
> >> Ivan
> >>
> >>
> >> On Friday, 11 January 2013 14:48:46 UTC, David Burns wrote:
> >>>
> >>> Hey All,
> >>>
> >>> I would like to propose a method name change.
> >>>
> >>> Currently to get the active element on the page we need to do
> >>>

> >>> driver.switchTo().**activeElement()

> >>>
> >>> which is not exactly what we are doing. We aren't switching to anything.
> >>> We are just doing a find element so would like to change to
> >>>

> >>> driver.findElement(By.active()**)

> >>>
> >>>
> >>> I would like to get your thoughts on this!
> >>>
> >>> David
> >>>
> >>> David Burns

> >>> URL: http://www.theautomatedtester.**co.uk/<http://www.theautomatedtester.co.uk/>
> >>>
> >> --
> >>
> >>
> >>
> >
> > --
> >
> >
> >
>
> --
>
>

[Bill Ross]

PS - when the element is 'invisible', getText() returns an empty string,
while click() throws an ElementNotVisibleException - seems inconsistent.

Plus: verified that elt is actually visible by

- check visibility: not visible
- take screenshot: shows visibility
- check visibility: not visible

All in a few milliseconds.

Bill

> --
>
>

[Mike Riley]

You should already be able to do that:

we.findElement(By.xpath("//.."))

I am not sure if the // is needed at the start or not, but I think it should work, even though I have never done it.  Give it a try.

Mike

[Luke Inman-Semerau]

no "//"  should just be By.xpath("..") for parent.

--
 
 

[Mark Collin]

To be safe you should really do:

 

By.xpath("./..")

--
 
 

[Simon Stewart]

Please don't hijack the thread. We're trying to keep this discussion focused on the activeElement change.

Simon

>
> --
>
>

--

[Bill Ross]

Sorry, looks like I missed your 'keep from exploding' comment. :-)

> --
>
>

[Simon Stewart]

:) NP

Simon

--

[Curtis Salisbury]

So just wondering if this has been implemented or not?

[David Burns]

This change has not be implemented. It has not been a priority.

David

David Burns
Email: david...@theautomatedtester.co.uk
URL: http://www.theautomatedtester.co.uk/

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/e415cce6-31e3-4902-8c60-038d8a43d875%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.