Hi Marcin,
Thanks for the reply. I have made some progress on this since my post and
your reply reminded me to come back and post a "solution". I put it in
quotes because it's more of a work around. The behavior in Chrome is
actually a chromium bug here
<https://bugs.chromium.org/p/chromedriver/issues/detail?id=2660>.
According to this bug report, it is fixed in Chrome v75 which is yet to be
released. As a work around for the moment, a Chrome Option can be added as
a capability:
chromeOptions.addArguments("--disable-site-isolation-trials")
capabilities.setCapability(ChromeOptions.CAPABILITY, chromeOptions)
For Firefox, I did initially have to have a waitFor{} in the withNewWindow
closure, but a page class also worked. Without doing either of those I
think the code was executing too fast and the stacktrace would indicate
that no new window was opened.
Thanks!
On Friday, March 29, 2019 at 2:20:18 AM UTC-5, Marcin Erdmann wrote:
>
> Sorry for a very late response but I’ve just came back from holiday.
>
> I cannot explain why using waitFor inside of a withNewWindow block would
> prevent the page in the new window from loading. To have a chance to
> understand that I would need to see the full stacktrace thrown after the
> browser sits there for 5 minutes.
>
> One way or another I would model your code differently. I tend to avoid
> explicit waitFor statements in my tests because they leak unnecessary
> details imho (usually you don’t care if somethig loads synchronously or
> asynchronously in your test). So I would model your check for the delayed
> page loading in the new window as a page class with an at checker
> preferably checking the content of the page and not the url, as well as
> having `static atCheckWaiting = true`. If we called it WellnessArticlesPage
> then your withNewWindow call could be changed to:
>
> withNewWindow({ click(page.wellnessArticlesLink)}, wait: true, page:
> WellnessArticlesPage) {}
>
>
> On Tue, 12 Mar 2019 at 15:56, <[email protected] <javascript:>> wrote:
>
>> Having an issue with a particular webpage using withWindow and
>> withNewWindow. I can't post the sites because they are internal sites, but
>> what is happening on one particular link is it opens a new tab and it takes
>> about 3 seconds for the page to load and it looks like there is a redirect
>> happening. I thought I could just bypass the redirect and using a waitFor
>> and waiting for the URL of the final page.
>>
>> def "click 'wellness articles and videos' link"(){
>>> given:
>>> at HomePage
>>>
>>> when:
>>> withNewWindow({ click(page.wellnessArticlesLink)},wait: true ) {
>>> waitFor {currentUrl.contains("url-here")}
>>> }
>>>
>>> then:
>>> at HomePage
>>> }
>>>
>>>
>> What is happening is it clicks the link and opens a new tab and then the
>> page stops loading after about 2 seconds, as if I am sending some kind of
>> stop command. It then sits there for about 5 minutes until the test
>> fails. I noticed if I only put a println statement in the withNewWindow
>> block instead of a waitFor or an assert then it works. So it seems like
>> the driver switching to the new tab is actually stopping the loading
>> somehow. The same thing happens when I use withWindow.
>>
>> Right now I have to resort to this:
>>
>>> def "click 'wellness articles and videos' link"(){
>>> given:
>>> page = at HomePage
>>>
>>> when:
>>> withNewWindow({ click(page.wellnessArticlesLink)},wait: true ) {
>>> sleep(3000)
>>> assert currentUrl.contains("url-here")
>>> }
>>>
>>> then:
>>> at HomePage
>>> }
>>>
>>>
>> That 3 second hard sleep prevents this issue from happening. I HATE
>> using hard sleeps though so this is not my preferred way. I haven't had
>> any issue with the withNewWindow function until now and in fact I am using
>> it in about 6 other tests just fine, but those sites don't seem to have a
>> redirect or anything.
>>
>> Any help is appreciated.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Geb User Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/geb-user/7972eda9-f860-4a8b-be98-b78309b5c5a5%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/geb-user/7972eda9-f860-4a8b-be98-b78309b5c5a5%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups "Geb
User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/geb-user/a4221c8f-802d-4cab-b5cc-feec9564e08a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
