Issue with element visibility in Mac Safari

[kepp...@networkoptix.com]

Hello again,

I have a number of test suites and cases that work on mac chrome, Windows Firefox, chrome, and edge, and Ubuntu Chromium.  But for some reason I have one element (ironically the log in button) that Safari always complains isn't visible.  Obviously it's visible and every other browser sees it with no problems.  Is there some quirk to Safari driver that I'm not aware of?  Is there a bug out there?  Any help would be appreciated.

Edit: Note that it is able to find other elements like opening the log in dialogue, typing in the user name and password, changing the language on the page.  But it gets upset about this one button.  Chrome on the same computer has no issues.

Edit2: Here is some code.  Again, works everywhere except Safari:

Log In

    [arguments]    ${email}    ${password}    ${button}=//nav//a[contains(@ng-click, 'login()')]

    Wait Until Element Is Visible    ${button}   #It fails here for some reason but every other browser finds it.

    Click Link    ${button}

    Wait Until Elements Are Visible    ${EMAIL INPUT}    ${PASSWORD INPUT}

    Input Text    ${EMAIL INPUT}    ${email}

    Input Text    ${PASSWORD INPUT}    ${password}

    Wait Until Element Is Visible    ${LOG IN BUTTON}

    Click Element    ${LOG IN BUTTON}

Extras in case they are needed:

Safari:11.0.3

MacOS: 10.13.3

Thanks,

Kyle

[kepp...@networkoptix.com]

Added more info and some robot code.

[Tatu Aalto]

Ugh

I don't recall seeing anything familiar with your problem. If you can not find anything from the Selenium issue tracker or by using Google, I would safely assume that you have found an issue with Safari or Safari driver. Please raise an issue to the Selenium issue tracker.

-Tatu
Send from my mobile

On Tue, 20 Mar 2018, 01:52 , <kepp...@networkoptix.com> wrote:

Added more info and some robot code.

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.
To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

[kepp...@networkoptix.com]

There is something similar on the selenium github but it was closed and the user was told to post the bug to the Safari team, so I went and made an account and reported it there.  Otherwise I'm not sure what to do.

On Tuesday, March 20, 2018 at 6:23:16 AM UTC-7, Tatu Aalto wrote:

Ugh

I don't recall seeing anything familiar with your problem. If you can not find anything from the Selenium issue tracker or by using Google, I would safely assume that you have found an issue with Safari or Safari driver. Please raise an issue to the Selenium issue tracker.

-Tatu
Send from my mobile

On Tue, 20 Mar 2018, 01:52 , <kepp...@networkoptix.com> wrote:

Added more info and some robot code.

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-users+unsub...@googlegroups.com.

[Dmitriy]

Hi,

It may be related to some css styles. Check in safari debugger wether button 

has width and height, topmost element, etc. Some css values requires 

-webkit prefix f.e. ‘display: -webkit-flex; backface-visibility: -webkit-…`

Thanks,

Dmitriy

On Mar 16, 2018, at 6:45 PM, kepp...@networkoptix.com wrote:

Hello again,

I have a number of test suites and cases that work on mac chrome, Windows Firefox, chrome, and edge, and Ubuntu Chromium.  But for some reason I have one element (ironically the log in button) that Safari always complains isn't visible.  Obviously it's visible and every other browser sees it with no problems.  Is there some quirk to Safari driver that I'm not aware of?  Is there a bug out there?  Any help would be appreciated.

Thanks,

Kyle

-- 
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.

[kepp...@networkoptix.com]

It definitely has a height and width.  Using the xpath in the inspector correctly finds the element as well.  Here is a shot of the html and computed styles.  I'm about to pull my hair out on this one.  I feel like it's got to be some small thing I'm missing.

Hi,

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-users+unsub...@googlegroups.com.

[Dmitriy]

First of all it is not a button it is a link. If you hover this element in debugger does it highlight? 

Like:

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.

[kepp...@networkoptix.com]

It show "Role link" but you can see in my robot code at the top that I used "Click Link".  Furthermore this is failing at "Wait Until Element Is Visible".

[Dmitriy]

As a possible workaround try to send ENTER key to this element.

[kepp...@networkoptix.com]

I have considered this as it would probably work.  However verifying that it is visible/clickable is important too.  I may have to put these instances into an if statement for when Safari is the selected testing browser.

Edit:  Correction, I can't send a key press to an element that isn't "visible" so that doesn't solve the problem either

Edit Edit: Ok I think I've solved my issue.  It is still specific to Safari but for the link I'm tying to click, if I look for visibility and click the parent element:

<span class="btn-wrapper">

It detects it as visible and clicking works successfully.  I don't know why Safari has an issue with this but I will have to refactor a lot of my tests in order to accommodate it.  Pretty annoying.

On Tuesday, March 20, 2018 at 11:44:19 AM UTC-7, Dmitriy wrote:

As a possible workaround try to send ENTER key to this element.

On Mar 20, 2018, at 11:39 AM, kepp...@networkoptix.com wrote:

It show "Role link" but you can see in my robot code at the top that I used "Click Link".  Furthermore this is failing at "Wait Until Element Is Visible".

On Tuesday, March 20, 2018 at 11:26:06 AM UTC-7, Dmitriy wrote:

First of all it is not a button it is a link. If you hover this element in debugger does it highlight? 

Like:

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-users+unsub...@googlegroups.com.

[Tatu Aalto]

Ugh

In my experience, testing with different browsers is waste of time. In my experience Chrome is the easiest to build stable UI automation. Firefox is about 10% to 20% harder than Chrome and IE is at least twice as hard as Firefox. I don't have deep knowledge from other browsers, but with little time spent on SeleniumLibrary cross browser testing, other browsers do not feel any easier than IE. Keeping the automation stable and providing good results is a hard job. Supporting multiple browsers makes it even harder and in my experience, the time spent on supporting multiple browsers does not pay off. Perhaps an example will share some light on the matter. If one spends one full work week doing browser automation for Chrome, then one extra day is spent, during next week, fixing automation for Firefox. If IE or something similar is added to the matrix, two to three more days more are spent on fixing and stabilization of the automation. Perhaps third new browser will take only a one day more. As a bottom line, that is one extra week solving problems with different browsers. So if one spends 30 weeks in a year doing test automation for different browsers, 15 weeks is actually spent on support and maintenance for other browsers. Would it be just easier not to do it and have better coverage with one browser. Also when bug is found which is due of different browser engine and it needs fixing, how long it takes to fix it and test it manually? One day, two days? One can fit quite many two days fixes in 15 weeks (to be precise 37 will fit) before it starts to pay off. I asked from work mate to calculate how many fixes they did make and the answer was more than 5 but less than 10. In my opinion and with the math above, cross browser testing does not pay off and I will choose better coverage with one browser any time. But that is just me and others may have a different opinion. But I hope that other have done some thinking does it pay off.

-Tatu
Send from my mobile

On 20 Mar 2018 19:20, <kepp...@networkoptix.com> wrote:

There is something similar on the selenium github but it was closed and the user was told to post the bug to the Safari team, so I went and made an account and reported it there.  Otherwise I'm not sure what to do.

On Tuesday, March 20, 2018 at 6:23:16 AM UTC-7, Tatu Aalto wrote:

Ugh

I don't recall seeing anything familiar with your problem. If you can not find anything from the Selenium issue tracker or by using Google, I would safely assume that you have found an issue with Safari or Safari driver. Please raise an issue to the Selenium issue tracker.

-Tatu
Send from my mobile

On Tue, 20 Mar 2018, 01:52 , <kepp...@networkoptix.com> wrote:

Added more info and some robot code.

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.

To post to this group, send email to robotframe...@googlegroups.com.

Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.

[Tatu Aalto]

Ugh

In my experience, testing with different browsers is waste of time. In my experience Chrome is the easiest to build stable UI automation. Firefox is about 10% to 20% harder than Chrome and IE is at least twice as hard as Firefox. I don't have deep knowledge from other browsers, but with little time spent on SeleniumLibrary cross browser testing, other browsers do not feel any easier than IE. Keeping the automation stable and providing good results is a hard job. Supporting multiple browsers makes it even harder and in my experience, the time spent on supporting multiple browsers does not pay off. Perhaps an example will share some light on the matter. If one spends one full work week doing browser automation for Chrome, then one extra day is spent, during next week, fixing automation for Firefox. If IE or something similar is added to the matrix, two to three more days more are spent on fixing  and stabilization of the automation. Perhaps third browser will take only a one day more. As a bottom line, that is one extra week solving problems with different browsers. So if one spends 30 weeks in a year doing test automation for different browsers, 15 weeks is actually spent on support and maintenance for other browsers. Would it be just easier not to do it and have better coverage with one browser. Also when bug is found which is due of different browser engine, in Edge for example, and it needs fixing, how long it takes to fix it and test it manually? One day, two days? One can fit quite many two days fixes in 15 weeks before it starts to pay off. In my opinion and with the math above, cross browser testing does not pay off and I will choose better coverage with one browser any time. But that is just me and other may have different opinions.

-Tatu
Send from my mobile

On Tue, 20 Mar 2018, 20:48 , <kepp...@networkoptix.com> wrote:

I have considered this as it would probably work.  However verifying that it is visible/clickable is important too.  I may have to put these instances into an if statement for when Safari is the selected testing browser.

On Tuesday, March 20, 2018 at 11:44:19 AM UTC-7, Dmitriy wrote:

As a possible workaround try to send ENTER key to this element.

On Mar 20, 2018, at 11:39 AM, kepp...@networkoptix.com wrote:

It show "Role link" but you can see in my robot code at the top that I used "Click Link".  Furthermore this is failing at "Wait Until Element Is Visible".

On Tuesday, March 20, 2018 at 11:26:06 AM UTC-7, Dmitriy wrote:

First of all it is not a button it is a link. If you hover this element in debugger does it highlight? 

Like:

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.

To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.

[kepp...@networkoptix.com]

That's an interesting point of view.  I will take this into consideration.  Frankly, I would agree with you that the pay-off might not be worth it but I will have to convince my superiors of that.  Thanks for your input!

On Tuesday, March 20, 2018 at 1:23:15 PM UTC-7, Tatu Aalto wrote:

Ugh

In my experience, testing with different browsers is waste of time. In my experience Chrome is the easiest to build stable UI automation. Firefox is about 10% to 20% harder than Chrome and IE is at least twice as hard as Firefox. I don't have deep knowledge from other browsers, but with little time spent on SeleniumLibrary cross browser testing, other browsers do not feel any easier than IE. Keeping the automation stable and providing good results is a hard job. Supporting multiple browsers makes it even harder and in my experience, the time spent on supporting multiple browsers does not pay off. Perhaps an example will share some light on the matter. If one spends one full work week doing browser automation for Chrome, then one extra day is spent, during next week, fixing automation for Firefox. If IE or something similar is added to the matrix, two to three more days more are spent on fixing  and stabilization of the automation. Perhaps third browser will take only a one day more. As a bottom line, that is one extra week solving problems with different browsers. So if one spends 30 weeks in a year doing test automation for different browsers, 15 weeks is actually spent on support and maintenance for other browsers. Would it be just easier not to do it and have better coverage with one browser. Also when bug is found which is due of different browser engine, in Edge for example, and it needs fixing, how long it takes to fix it and test it manually? One day, two days? One can fit quite many two days fixes in 15 weeks before it starts to pay off. In my opinion and with the math above, cross browser testing does not pay off and I will choose better coverage with one browser any time. But that is just me and other may have different opinions.

-Tatu
Send from my mobile

On Tue, 20 Mar 2018, 20:48 , <kepp...@networkoptix.com> wrote:

I have considered this as it would probably work.  However verifying that it is visible/clickable is important too.  I may have to put these instances into an if statement for when Safari is the selected testing browser.

On Tuesday, March 20, 2018 at 11:44:19 AM UTC-7, Dmitriy wrote:

As a possible workaround try to send ENTER key to this element.

On Mar 20, 2018, at 11:39 AM, kepp...@networkoptix.com wrote:

It show "Role link" but you can see in my robot code at the top that I used "Click Link".  Furthermore this is failing at "Wait Until Element Is Visible".

On Tuesday, March 20, 2018 at 11:26:06 AM UTC-7, Dmitriy wrote:

First of all it is not a button it is a link. If you hover this element in debugger does it highlight? 

Like:

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-users+unsub...@googlegroups.com.

To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-users+unsub...@googlegroups.com.

[Bryan Oakley]

My views are similar to Tatu's. It depends on just how critical your need is to support other browsers with perfect fidelity, but for a large number of products, getting passing tests on chrome and firefox and then a manual spot-check of the other browsers is usually good enough. Instead of spending dozens if not hundreds of hours dealing with failing tests on safari and edge,  you can spend a couple hours each release cycle manually checking for browser-specific bugs. When you find a genuine difference, you can write a test for that one specific thing. Over time you might have 1000 tests run on chrome and firefox, but maybe just a dozen or so on the other browsers. 

It boils down to how critical support of browsers other than chrome and firefox is, and how many resources you have to throw at the problem. If you're google, you can afford to have automated tests for every platform. If you're a small shop it might be worth doing back-of-the-envelope cost/benefit analysis before spending multiple hours trying to fix one test on one browser. 

On Tue, Mar 20, 2018 at 4:01 PM, <kepp...@networkoptix.com> wrote:

That's an interesting point of view.  I will take this into consideration.  Frankly, I would agree with you that the pay-off might not be worth it but I will have to convince my superiors of that.  Thanks for your input!

On Tuesday, March 20, 2018 at 1:23:15 PM UTC-7, Tatu Aalto wrote:

Ugh

In my experience, testing with different browsers is waste of time. In my experience Chrome is the easiest to build stable UI automation. Firefox is about 10% to 20% harder than Chrome and IE is at least twice as hard as Firefox. I don't have deep knowledge from other browsers, but with little time spent on SeleniumLibrary cross browser testing, other browsers do not feel any easier than IE. Keeping the automation stable and providing good results is a hard job. Supporting multiple browsers makes it even harder and in my experience, the time spent on supporting multiple browsers does not pay off. Perhaps an example will share some light on the matter. If one spends one full work week doing browser automation for Chrome, then one extra day is spent, during next week, fixing automation for Firefox. If IE or something similar is added to the matrix, two to three more days more are spent on fixing  and stabilization of the automation. Perhaps third browser will take only a one day more. As a bottom line, that is one extra week solving problems with different browsers. So if one spends 30 weeks in a year doing test automation for different browsers, 15 weeks is actually spent on support and maintenance for other browsers. Would it be just easier not to do it and have better coverage with one browser. Also when bug is found which is due of different browser engine, in Edge for example, and it needs fixing, how long it takes to fix it and test it manually? One day, two days? One can fit quite many two days fixes in 15 weeks before it starts to pay off. In my opinion and with the math above, cross browser testing does not pay off and I will choose better coverage with one browser any time. But that is just me and other may have different opinions.

-Tatu
Send from my mobile

On Tue, 20 Mar 2018, 20:48 , <kepp...@networkoptix.com> wrote:

I have considered this as it would probably work.  However verifying that it is visible/clickable is important too.  I may have to put these instances into an if statement for when Safari is the selected testing browser.

On Tuesday, March 20, 2018 at 11:44:19 AM UTC-7, Dmitriy wrote:

As a possible workaround try to send ENTER key to this element.

On Mar 20, 2018, at 11:39 AM, kepp...@networkoptix.com wrote:

It show "Role link" but you can see in my robot code at the top that I used "Click Link".  Furthermore this is failing at "Wait Until Element Is Visible".

On Tuesday, March 20, 2018 at 11:26:06 AM UTC-7, Dmitriy wrote:

First of all it is not a button it is a link. If you hover this element in debugger does it highlight? 

Like:

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-users+unsubscrib...@googlegroups.com.

To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-users+unsubscrib...@googlegroups.com.

To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-users+unsub...@googlegroups.com.

To post to this group, send email to robotframework-users@googlegroups.com.

[Tatu Aalto]

Ugh

If you have to do that, which should be team decision not your bosses (but I am not going to rant about that, because that is totally different topic), doing what Bryan suggested is a good idea. Example estimate how much money is spent doing the cross browser automation and how much is gained by the automation. First think, how much effort supporting different browsers requires extra work from your team, in hours. Don't forget all the environment hassle and installing different browsers. Take your average hour salary and turn the hour number to money. Then look at past bugs and find out the ones that are related to browser compatibility, try to figure out how much time it took to fix them. Turn the fix hours to money. If the numbers support the idea of dropping the browser compatibility testing, think how the problem will be handled. Do you need some resources, like virtual machine, where the bug can be reproduced easily. Are you able to fix the urgent issues in fast pace. Is something extra needed? Turn the numbers and ideas in to presentation. First sell the idea to your team and then to your boss. And remember this doesn't mean less automation, it means more automation with a single browser. Better coverage, more stable test and therefore better feedback for the team. Should not be hard to sell, if the money supports the idea.

-Tatu
Send from my mobile

On 20 Mar 2018 23:01, <kepp...@networkoptix.com> wrote:

That's an interesting point of view.  I will take this into consideration.  Frankly, I would agree with you that the pay-off might not be worth it but I will have to convince my superiors of that.  Thanks for your input!

On Tuesday, March 20, 2018 at 1:23:15 PM UTC-7, Tatu Aalto wrote:

Ugh

In my experience, testing with different browsers is waste of time. In my experience Chrome is the easiest to build stable UI automation. Firefox is about 10% to 20% harder than Chrome and IE is at least twice as hard as Firefox. I don't have deep knowledge from other browsers, but with little time spent on SeleniumLibrary cross browser testing, other browsers do not feel any easier than IE. Keeping the automation stable and providing good results is a hard job. Supporting multiple browsers makes it even harder and in my experience, the time spent on supporting multiple browsers does not pay off. Perhaps an example will share some light on the matter. If one spends one full work week doing browser automation for Chrome, then one extra day is spent, during next week, fixing automation for Firefox. If IE or something similar is added to the matrix, two to three more days more are spent on fixing  and stabilization of the automation. Perhaps third browser will take only a one day more. As a bottom line, that is one extra week solving problems with different browsers. So if one spends 30 weeks in a year doing test automation for different browsers, 15 weeks is actually spent on support and maintenance for other browsers. Would it be just easier not to do it and have better coverage with one browser. Also when bug is found which is due of different browser engine, in Edge for example, and it needs fixing, how long it takes to fix it and test it manually? One day, two days? One can fit quite many two days fixes in 15 weeks before it starts to pay off. In my opinion and with the math above, cross browser testing does not pay off and I will choose better coverage with one browser any time. But that is just me and other may have different opinions.

-Tatu
Send from my mobile

On Tue, 20 Mar 2018, 20:48 , <kepp...@networkoptix.com> wrote:

I have considered this as it would probably work.  However verifying that it is visible/clickable is important too.  I may have to put these instances into an if statement for when Safari is the selected testing browser.

On Tuesday, March 20, 2018 at 11:44:19 AM UTC-7, Dmitriy wrote:

As a possible workaround try to send ENTER key to this element.

On Mar 20, 2018, at 11:39 AM, kepp...@networkoptix.com wrote:

It show "Role link" but you can see in my robot code at the top that I used "Click Link".  Furthermore this is failing at "Wait Until Element Is Visible".

On Tuesday, March 20, 2018 at 11:26:06 AM UTC-7, Dmitriy wrote:

First of all it is not a button it is a link. If you hover this element in debugger does it highlight? 

Like:

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.

To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.

To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.