Chrome, Opera support

[Pakema]

Hi!

TC support Opera: Just add in MSAA "OpWindow"

TestComplete 7.52 + Opera 10.53 (in screen)

[krainevsky]

Wow! Thanks, Nikita!



I've updated Opera from 10.51 and I can see the improvements in Object Tree 🙂 



But it is not the support I need actually. I need access to DOM through the browser methods and access to the script engine of the browser. I'm not really shure that I can get this through the MSAA.



Anyway, thanks again and we are still waiting for 100% Chrome support.

[krainevsky]

It looks like the Google Chrome doesn't support TestComplete anymore 🙂 . I've just updated to Google Chrome 5 and tried to open TestComplete's logs exported to HTML. Now they looks like as at the attached picture.

[AlexKaras]

I definitely don't know details and actual reasons, but somewhere in time there was an explanation from Automated's Support that TC mainly supports IE and Firefox just because all other browsers do not provide reliable support for external access (i.e. testing tools cannot access their internals like in case of IE and FF).

I expect the progress in this area (as I assume AQA's contacts with the providers of other browsers) like it was, for example, for Delphi - for several versions TC required additional modules to be compiled with Delphi application to make it Open for TC. Latest TC versions do not require this. But this took some time to be implemented.



P.S. Personally I prefer support of WPF web services rather than several more browsers...

[krainevsky]

I guess this will be interesting for some TC users and developers:



1. Go here: http://code.google.com/chrome/chromeframe/ ,download and install Google Chrome Frame.

2. Modify your test pages as it said here: http://www.chromium.org/developers/how-tos/chrome-frame-getting-started. In the simpliest  case you have to add <meta http-equiv="X-UA-Compatible" content="chrome=1"> to the test page.
3. Run test complete, open project properties at "Open Applications -> MSAA". Add two classes to the list: "Chrome_WidgetWin_0" and "Chrome_RenderWidgetHostHWND"
4. Run Internet Explorer (I used IE8) and open your modified page.
Results:
Now your test page is rendered with chrome engine.
Now you are able to see some object's from the page through MSAA (see attach).

[Pakema]

As we know: Netscape Navigator ver. 8 can display web pages using Firefox's or Internet Explorer's rendering engine. 

http://www.automatedqa.com/support/viewarticle.aspx?aid=7588

Well let's try repeat this with Google Chrome.So you need:

1. install in Chrome "IE Tab" Extention.

2. Check in MSAA "Internet Explorer_Server"

AND THEN WE CAN - see attach

TC - 7.52 + Chrome 4.1

[AlexKaras]

Hi,



I might miss the reasons for replacing the rendering engine with another one, but I think that:

-- The logic for Web applications can be split on server (actual data) and client (data visualization) parts;

-- The logic of the server part should not depend on the browser;

-- The client logic (i.e. data visualization) depends on the given rendering engine and on how rendered data are displayed by the given browser.

Unless there are explicit requirement to test how the given browser works with non-native renderer it is not reasonable to execute the browser with susbtituted rendering engine.



Considering the above I see no good reason for running tests on browsers with non-native rendering engine...

[krainevsky]

Hi,



You are absolutely right Alexei! There are no good reasons in the list you posted above for using non-native rendering engine. But if we add to your list some new thoughts like:

 - We use TC for autotests

 - TC doesn't support some popular browsers

 - We need to test under the browsers which are not supported by TC

we'll see definetly different picture. I hope this help you to understand reasons for using non-native rendering engine.

[AlexKaras]

Hi Alexander,



> - TC doesn't support some popular browsers

> - We need to test under the browsers which are not supported by TC



The above is evident. But according to my understanding, substitution of the rendering engine does not mean that TestComplete begins to support unsupported browsers. From my point of view, in this case TestComplete just gets a possibility to access tested web page elements and control these elements via rendering engine. I guess (and I hope that Automated's Support will correct me if my guess is wrong) that, for example, with IE, TestComplete does not interact with IE itself, but interacts with its rendering engine. So, when, for example, Chrome uses IE's rendering engine and TestComplete is used to control this combination, this means that TestComplete still works with the same IE engine. The only difference is that rendered content is displayed not in IE, but in Chrome. The disadvantage of this approach is that it is not possible to say anything as for how the given page will be rendered and displayed in Chrome using its native renderer. Also, if something is shown incorrectly, it is not possible to say if the problem was caused by the IE renderer or how Chrome displays data provided by non-native renderer.



Considering the above, I still don't see the reason to substitute the rendering engine in unsupported browsers. (Unless there is explisit task to check how the data provided by the non-native renderers are displayed by this or that browser.)

[krainevsky]

Hi Alexei,



I think I've found the cause of your misunderstanding of our problems. The point is that I'm not going to swap Chrome's render engine for IE engine to make "TC support Chrome". I'm going to do the opposite: use Chrome's render engine inside IE.

I see the following disadvantages of this approach:

 - Using this trick cause appearing bugs that can not be reproduced at the real Chrome.

 - Additional resources(time, people, money...) needed to make changes inside the core of the autotests(it depends)

 - No guarantees that this will work, cause no one tested this

But this approach is not so bad cause:

 - This is the only way to test Chrome with TestComplete at the moment (except coord-testing).

 - You can use test results from this IE-Chrome integration (only if you keep in mind that this is not real Chrome).

 - If you succeed at the rewriting your tests you can save resources cause you still use automated testing and cause you still use one automation tool.



Please, correct me if I'm wrong or miss something.

ty.