TimeoutError on page.goto

Libraries Browser
1

Hi ,

it seems like Browser library is waiting for all http requests to complete before starting with page elements interaction.
Even though page is loaded (js wise) and page is interactable, some calls to google analytics and other 3rd party are taking long time and causing timeout error (we used 20 seconds).
did anyone encounter this issue?
anything i can do to further debug it?
if this is indeed the case, can I disable wait for subsequent requests (or use regex for which domains to wait) ?

thanks,

2

Hi Oren,

First before trying to work around an issue like this, I would would argue that is an application defect that your development team should be “fixing” by removing those 3rd party components if they are not absolutely necessary.

Of course that was a very pious answer from my high horse and reality doesn’t always meet with our ideals :rofl:

The builtin library has options like Run Keyword And Expect Error and Run Keyword And Ignore Error for dealing with things like this, you may even want to temporarily shorten the timeout for that (those?) page load(s) so the time out error is predictable.

Another option might be a simple “infrastructure” fix of using a proxy server that caches these elements.

But I would really want to report upstream that the end user will experience these timeouts, not having those 3rd party elements loaded may lead to unpredictable user experience if your devs are relying on them for UI theming etc, as for google analytics if that’s timing out then the analytics results are not going to be reliable, and so therefore not really providing any value, since you’ve proven that to be the case it can be removed too.

Hope this helps,

Dave.

1 Like
3

thanks Dave, but removing 3rd party requests is not an option and proxy solution usually brings more issues than the ones it should solve (been there).
I am wondering :

  1. if indeed Browser waits for all subsequent requests, and
  2. if there is a way to WA it by using some flag.

for me it does not make sense that requests that has absolutely no impact on page DOM would block interaction with the page.

4

You could extend Browser library with custom JavaScript keyword that will instruct browser to abort some requests.

async function CancelRequestsToExample(page) {
  page.route('https://example.com/*', route => {
    return route.abort();
  });
}
exports.__esModule = true;
exports.CancelRequestsToExample = CancelRequestsToExample;

While loading Browser library add one parameter jsextension=path_to_my_kw.js. And after that you could call Cancel Requests To Example in suite setup for instance.

5

Hi Oren,

  1. Browser Go To waits for “the page to load” (I assume this means it waits until the webbrowser reports that page has finished loading and that behaviour could vary depending on the browser)

  2. There are a few possible work arounds:

  • you could increase the time out either for all requests with Set Browser Timeout or for this specific request with the timeout option
  • you can wrap this keyword with a expect error or ignore error keyword from the builtin library (see my previous post)
  • An infrastructure workaround I mentioned earlier

My original point was that if you are receiving a timeout and the page should have been loaded within that timeout then really this is an application bug, so before trying to implement a work around in the test case some pressure should be applied to the development team (or architecture team?) to fix their bugs.

Always remember when there are issues in production, the test team are always the first to have the finger pointed at them (the first to receive the blame), you want to protect yourself, raising a defect and allowing the test case to fail and reporting it as a fail is part of this protection, then when it becomes a production issue you have documented evidence that it was reported/failed. if you then get overruled by someone, ensure that overruling is documented then implement your work around and reference the defect as a comment with the work around, then when the finger is pointed at you, pull the defect out and let the finger go to the person who overruled you.

You don’t have to take my advice, it’s your reputation, but I have seen too many projects where the testing team was recruited for the purpose of having a scape goat, I don’t want that to happen to you.

Dave.

1 Like
6

hi Dave,
thanks again, I think you are missing the point a little.
There is no problem with page loading, the long or failing requests to 3rd party URLs have 0 impact on page loading. in worst scenario, we will miss analytics or other nice-to-have capability which has nothing to do with end user experience.
Since this is the case, and knowing that we have no control on 3rd party URLs and their availability, I would like to simply ignore the requests made to them in the tests and focus on testing our application.
we already increased timeout which solved the issue but I don’t like it at all and IMO it bad practice to increase timeout since it hides real application issues in this case.
therefore WA for ignoring none important request is the ideal solution for us, like others have suggested.

7

Hi Oren,

I’m not the developer for the Browser Library just a user like you.

If you think there is a need/value for this type of work around, then I suggest you raise a feature request for it.

Probably because I come from a performance testing background I have a different perspective on how systems should behave.

Dave.