Forum Discussion

Colin_McCrae's avatar
Colin_McCrae
Community Hero
9 years ago

Chrome inconsistent behaviour with TC11.20

Since the NPAPI plugin was switched off, I haven't had much cause to run my large test suite which uses Chrome.

 

I was asked to run it yesterday and have found a rather large problem (from my perspective).

 

I have been running these tests for a couple of years now and with the old NPAPI plugin, all was well. With whatever it's been replaced with, all is no longer well.

 

Context:

 

I run multiple instances of Chrome during the test.

Each instance is on a different URL. So I identify the page by URL.

I send "Keys" to the Page object of each different browser.

Sometime the browsers open (there can be up to 5) have to be full screen. So they are not always all visible.

 

Using the NPAPI plugin, I was able to send "Keys" to any page, regardless of whether it was the one currently in the foreground or not. Now, that does not seem to be the case.

 

With 3 broswers open - device10, device11, device12. Opened in that order so device12 is on top, then 11, then 10.

 

I assign the device10 page to an object before I interact with it. I've put in a breakpoint and checked that the correct page has been assigned. It has. It then sends the Keys to the page. But the keypress is not going to device10, it's going to device12. (I can see this as device12 flashes in the task bar when the keypress is sent)

 

In other words, it send the Keys to the browser on the top of the pile.

 

This has not been thge behaviour for the last couple of years. Keys went to the correct browser, regardless of whether they were in focus/on top. This is causing masses of false failures in my (large - approx 5 hour run) tests.

 

When investigating, I notice that the properties of Chome pages don't seem to be right either. All 3 browsers show "VisibleOnScreen" as TRUE. Which is wrong. They are all full screen. Only the top one is visible.

 

I'm going to have to try and find some sort of hacky workaround to force it to bring the browser/page I want into focus/foregound, which is not ideal. So far, it seems I'll have to use the BrowserWindow object associated with the page as it offers an "Activate" method. The Page object does not. The first child Panel of page also does not. It does offer a "Focus" method, but this does nothing. It does not bring the browser/page to front. Doing a sys.refresh at various points also makes not difference. Using BrowserWindow is not ideal as the link between each Page and it's BrowserWindow object is not obvious by the URL .... which is the way I tell them apart currently. I'm going to have to hack in some sort of search for an identifier name within the page and then match that to the BrowserWindow caption. Horrible.

 

Not sure where else I'm going to run into similar problems where things used to work in the background and now don't. I'll only find out as I fix things bit by bit.

 

But sending Keys to the wrong browser (despite the correct one being identified and assigned correctly beforehand) is already a major problem for me. Huge tests which I've been running successfully for years are now a complete mess thanks to this.

5 Replies

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3

    Hi Colin,

     

    Just in case - maybe the below function will help (it returns the Window that is parent for the given Page so you can Activate it):

     

    '-----------------------------------------------------------------------------

    ' Returns BrowserWindow object that corresponds to the given page object
    ' From: http://smartbear.com/forums/f75/t83264/how-to-match-a-page-object-to-its-browserwindow
    Function BrowserWindowByPageGet(ByRef page)
      Const cProcName = "BrowserWindowByPageGet"
      Dim cProcNameMsgPrefix : cProcNameMsgPrefix = cUnitNameMsgPrefix & cProcName & "(): "

     

      Dim title
      Dim wnd
      Dim strMsg

     

      Set wnd = Utils.CreateStubObject
      If (Not IsNull(page)) Then
        If ("Page" = page.ObjectType) Then
          strMsg = "Waiting for the page to load from the web server..."
          Do Until aqObject.IsSupported(page, "contentDocument")
            Call aqUtils.Delay(500, strMsg)
          Loop
          Do Until BuiltIn.varDispatch = aqObject.GetVarType(page.contentDocument)
            Call aqUtils.Delay(500, strMsg)
          Loop
          Do Until aqObject.IsSupported(page.contentDocument, "title")
            Call aqUtils.Delay(500, strMsg)
          Loop

     

          title = page.contentDocument.title
          Set wnd = page.Parent.FindChild("WndCaption", title & "*")
          If (Not wnd.Exists) Then
            Set wnd = page.Parent.FindChild("WndCaption", Project.Variables.pvtBaseURL)
          End If
        End If
      End If
      Set BrowserWindowByPageGet = wnd
    End Function
    '-----------------------------------------------------------------------------

     

    • Colin_McCrae's avatar
      Colin_McCrae
      Community Hero

      Thanks Alex

       

      Handy for future reference.

       

      In the end, using the caption was simple enough after the devs made some mods to the code to include part of the URL (the same part I use to identify the page) in the caption. In end use, the browser is full screen and an embedded system so tabs, nav bars, browser buttons etc are not visible to the end user thus we can use them as we see fit. Which was handy for me. So three lines of code in a couple of strategic places has sorted it out in the end. (The project in question sends all key press events at page level. So there are only two keypress routines in use by the whole project. One for short presses - using Keys(), one for long presses - using KeyUp/KeyDown. These were the only places I need to put the activation code in.)

       

      I still need to have a poke around and find out why the browser doesn't activate when you send things to the page. It used to using the NPAPI driver. But doesn't using whatever it uses now. But not in all cases. I think it may have something to do with how the browser is started. Was hoping to check that out last week but had to focus on getting all the tests working and run.

       

      Hopefully checking that out today and will raise a support ticket accordingly.

       

      ** EDIT **

       

      Just wondering if you have tried the above with Chrome and it worked consistently?

       

      One problem I had in the past with Chrome was using "page.contentDocument". It has a "readyState" property which does not work properly. Or at least, it didn't when I hit this problem. See below:

       

      http://community.smartbear.com/t5/Functional-Web-Testing/contentDocument-readyState-always-quot-complete-quot-in-Chrome/m-p/89758

       

      As I wonder if might send you off to the BrowserWindow object before it's fully ready and populated becuase of the same problem?

  • Oh ... and just to add.

     

    I don't know why, but after doing a lot of messing about in a sandbox with my 3 open browsers, it does eventually seem to start working and identfying and sending methods to them correctly. Although I haven't worked out what the trigger is that causes this yet.

    • UnveN's avatar
      UnveN
      Staff

      Hello,

       

      The behaviour is surely wrong and needs to be investigated by us. I suggest you to open a support ticket considering this issue.

      • Colin_McCrae's avatar
        Colin_McCrae
        Community Hero

        I think you're right.

         

        I have my hacky workaround in place now, so my tests work again (and will continue to work without removing it if/when this is fixed).

         

        That was the priority yesterday.

         

        Now that I at least have a working set of tests again, I'll do some more poking about today and see if I can work out what the triggers that make it work or not work with multiple browsers as it doesn't seem to be consistent. I suspect it may be something to do with the way I start the browsers. I'll try a few things and see if I can work it out in more detail rather than raising a vague support ticket.