When AUT behaves differently in RxBrowser vs Safari

Mobile Testing, Android App Testing.
gilbar16
Posts: 109
Joined: Wed Mar 26, 2014 6:23 pm

When AUT behaves differently in RxBrowser vs Safari

Post by gilbar16 » Wed Oct 14, 2015 5:49 pm

What do you do when the mobile web application you are testing behaves differently in RxBrowser as compared to Safari?

Our AUT has some type of comboboxes or dropdown lists where when run in Safari, the user can only scroll up and down the list to select an item.
When run in RxBrowser, the user can also type in the first few letters/characters and the target item is narrowed down for selection (example: typing "LO" shows the items that starts with "LO" like "LONG BEACH", "LOS ANGELES", etc.) in addition to scrolling up and down the list to select an item.

Btw: Does the RxBrowser behaves more like Internet Explorer or Chrome or Safari or ???

Appreciate any input you might have.

Thanks.
Gilbert

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: When AUT behaves differently in RxBrowser vs Safari

Post by Support Team » Thu Oct 15, 2015 11:11 am

Hi Gilbert,

The RxBrowser on iOS is a simple iOS application that uses the standard WebView from iOS. Unfortunately, this webview is slightly different than the built-in Safari browser.

As a workaround you could use a User Agent switcher on your desktop browser. This would allow you to simulate the same behavior as on a mobile browser.

Hope that helps.
Regards,
Markus (S)
.
Image

gilbar16
Posts: 109
Joined: Wed Mar 26, 2014 6:23 pm

Re: When AUT behaves differently in RxBrowser vs Safari

Post by gilbar16 » Thu Oct 15, 2015 5:34 pm

Hi Markus,

How about in Android devices?
Will the RxBrowser behave the same way as Chrome or whatever browser is installed or running in Android device?

I guess I have to google the User Agent switcher, since I have not done that before, to try out.

Thanks.
Gilbert

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: When AUT behaves differently in RxBrowser vs Safari

Post by Support Team » Fri Oct 16, 2015 1:06 pm

Hi Gilbert,

Since Android 4.4, the Ranorex Browser is based on the Chromium WebView.

Therefore, our browsers are working in the same way as the standard browsers of the corresponding operating system on your device do.

Regards,
Markus (S)
.
Image

gilbar16
Posts: 109
Joined: Wed Mar 26, 2014 6:23 pm

Re: When AUT behaves differently in RxBrowser vs Safari

Post by gilbar16 » Thu Oct 22, 2015 12:59 am

Hi Markus,

In most cases, yes the RxBrowser is behaving like the other browsers like Chrome in particular.
In other cases, even the RxBrowser in Android is behaving differently than the RxBrowser in iOS.
An example in our AUT, the scrolling of a page is working fine in Android but not in iOS. At the bottom of the screen, there are 3 buttons/links that are kind of blocking some other controls/links. The user can scroll the screen up and those hidden links/controls become visible and available. In the iOS RxBrowser v2.1.2, the scrolling is not properly working: when the user scrolls up the screen, the 3 buttons goes along with the rest of the page contents so the controls being blocked by these buttons remain blocked. (this is happening in an iPAD Air 2 running the latest 9.0.2 version of the iOS)

The other issue is with popups.
Using Chrome, IE, Safari, or Firefox, clicking on a link in our AUT navigates to a different website/URL after you take care of the message like "Popup is blocked". In RxBrowser (both Android and iOS), the message does not even come up so the navigation to the target silte/URL does not happen.

Is there any settings or options in Ranorex or RxBrowser that can be set to allow pop ups or let you exit out of your current website/URL and bring to a new site/URL?

Thanks.
Gilbert
Last edited by gilbar16 on Tue Oct 27, 2015 1:01 am, edited 1 time in total.

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: When AUT behaves differently in RxBrowser vs Safari

Post by Support Team » Fri Oct 23, 2015 9:46 am

Hi Gilbert,

Would it be possible to get access to your website under test? I’d like to analyze the problem directly on our side.

Concerning popups
I’m afraid that popups are currently not supported by our RxBrowser. If you would like to raise a feature request, I may ask you to contact us by email ([email protected])?
We would like to handle feature requests via email in order to avoid misunderstandings.

Thank you in advance.

Regards,
Markus (S)
.
Image

gilbar16
Posts: 109
Joined: Wed Mar 26, 2014 6:23 pm

Re: When AUT behaves differently in RxBrowser vs Safari

Post by gilbar16 » Fri Oct 23, 2015 6:08 pm

Hi Markus,

Unfortunately, our mobile apps is only accessible by people in-house for now until it gets release to the public. Quite different when working in the Healthcare industry due to all the Security stuffs like PHI (patient's info) so I won't be able to share with you. The closest we can do is share screens in webex or goto meetings or share screenshots.

Yes, I have been emailing Ranorex Support on issues lately and the person assigned to us is Andy Suarez and he's been very helpful.

Thank you.
Gilbert


Our mobile app currently being tested targets Chrome and Safari and Android browsers mainly so I'm hoping we won't see too many differences between those browsers mentioned and the RxBrowser. Otherwise, the bosses may tell us the testing we are doing with Ranorex may not be good enough. :<

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: When AUT behaves differently in RxBrowser vs Safari

Post by Support Team » Thu Oct 29, 2015 4:08 am

Hello Gilbert,

I have responded in detail to your email regarding this issue that was submitted via the Support Inbox. In order to properly track the status of this issue, lets continue to use the support inbox as the main method of communication.

Thanks,

Andy S.
.
Image