Roku Developer Program

Developers and content creators—a complete solution for growing an audience directly.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
AccedoANZ
Level 7

Roku automation framework - getFocusedElement does not return correct focused element

The webdriver doesn’t seem to be able to interpret what the focused element is correctly in the majority of places within the app. Instead of returning the focused element, getFocusedElement returns a key on the virtual keyboard that it seems to think is focused instead. The keyboard is not on screen or visible.This makes navigation through the app almost impossible.

Does anyone know why this is happening and if there is a solution?

0 Kudos
6 REPLIES 6\
AccedoANZ
Level 7

Re: Roku automation framework - getFocusedElement does not return correct focused element

One further finding we have come across in the meantime re the above is the following

We've discovered that the keyword grabs ALL of the elements that have the attribute "focused" and seems to return the last one it finds

0 Kudos
miketheiss
Level 7

Re: Roku automation framework - getFocusedElement does not return correct focused element

I have also experienced this.   In the channel I am testing it is not happening for most items.  However, there are some places where the "active" element I get backed from Web driver is not at all what I was expecting or what the user sees as focused.

I have been using a lot of specific element locators  in my tests and I'm doing a lot of external parsing of the JSON that comes back from those queries in my assertions as opposed to relying on the "active" element query a lot.

 

0 Kudos
sudoscience
Level 7

Re: Roku automation framework - getFocusedElement does not return correct focused element

Has anyone figured this out? I'm having a similar problem where it only seems to return the last "focused" element and not the one I am expecting and it is only happening for the one app I am testing. I've loaded the sample channels that Roku has in their repos and it seems to work fine there. Other people with the same zip file as me are not running into this issue either

0 Kudos
miketheiss
Level 7

Re: Roku automation framework - getFocusedElement does not return correct focused element

Which version of the framework are you using?    There was a bug in the first few versions of the framework (v 1.0 and v 2.0) which caused the original issue reported here.   They issued a fix in the v 2.1 release, so if you update to latest I would expect that would fix it for you.  I have used up to v 2.2, but have not used v 2.3, which just came out last month.

Release info at the bottom of this page:
https://developer.roku.com/en-ca/docs/developer-program/dev-tools/automated-channel-testing/automate...

Warning:   they fundamentally changed the way that element/elements queries return data in 2.1 and 2.2.    I found that queries for nested elements that worked as I would have expected in previous versions did not return matches after updating to 2.1 / 2.2.   This was not a clearly documented change.   After updating, I had to directly query parent or child elements and do additional parsing in some cases, so if you are using an older version, you may need to update some of your queries after updating, depending on how your queries are written.

0 Kudos
sudoscience
Level 7

Re: Roku automation framework - getFocusedElement does not return correct focused element

Oh my god, that was it!! Turns out I was running an old version, updating it fixed the issue. Thank you so much for the quick and detailed response!!!!

miketheiss
Level 7

Re: Roku automation framework - getFocusedElement does not return correct focused element

That has been my experience as well @osle83.  In some cases, your experience will vary depending on the channel design.  A team I worked on created custom rowlist elements with lazy loading capability to address performance concerns on large pages with long rows full of content.   Prior to the lazy loading implementation, if the cursor was focused on a tile, Webdriver would see the focused element as the tile.  After the implementation, WebDriver saw the focus as being on the row, but to the user, the tile appeared focused and behaved as designed.    In some cases I had to adapt the tests to parse the visual elements, colors, opacity, etc. to determine whether items had the appearance of focus vs. actually having a focused=true property on the element.    It's likely that something could have been done differently from the channel development side to avoid this, but since our main goal was to support the user experience and the user experience was acceptable, I adapted my tests to adjust to the channel design.

 

0 Kudos