WebDriver UDF (W3C compliant version) - 2024/09/21

[NguyenLe]

On 30/1/2018 at 6:53 PM, Danp2 said:

@NguyenLe Please define "turn off the display". I interpret that to mean that you turned off the computer monitor. However, it could also mean hiding the browser window like I mentioned here --

Which of these is the correct interpretation? Also, post some code showing the issue so that we can try it on our end.

Hello @Danp2 ,

It seems to have returned to normal after I restarted my computer
Thank you very much

[Danp2]

Just released updated version on GH. I stuck with using the existing WinHTTP UDF for the following reasons --

• The WinHTTP UDF is well defined and tested
• It avoids all issues related to COM errors, alternative error handlers, etc
• I'm not concerned about the differences in licensing
• It was working fine in my testing

Look forward to your feedback / testing. 

[mLipok]

Do you want me to do a PullRequest for COM Error Handling ?

Today I have some spare time.

 

[Danp2]

@mLipok At this time, I would say no because the UDF doesn't use any COM objects.

Take a look at the current implementation and let me know what you think.

 

[mLipok]

Did you anywhere on GitHub put link to this AutoIt Forum Support Topic  ?
Did you put this link also into core UDF ?

 

Edited February 1, 2018 by mLipok

[Danp2]

Thanks for your suggestions. I added the link to the ReadMe on GH. I will add it to the UDF shortly.

 

[NguyenLe]

@Danp2 If I connect to a new tab and reconnect to the previous tab I can not get the text of the alert

My Code: 

_WD_Startup()
$sSession = _WD_CreateSession($sDesiredCapabilities)
_WD_Navigate($sSession, 'http://google.com')
_WD_ExecuteScript($sSession, 'window.open()','{}')
$Handle = _WD_Window($sSession, 'handle', '')
;Sleep(500)
_WD_NewTab($sSession, True)
Sleep(500)
_WD_Window($sSession, 'Switch' ,'{"handle":"' & $Handle & '"}')
Sleep(500)
_WD_ExecuteScript($sSession, "alert('testing 123')")
Sleep(1000)
$aHandles = _WD_Window($sSession, 'handles', '')
$sTabHandle = $aHandles[UBound($aHandles) - 1]
_WD_Window($sSession, 'Switch', '{"handle":"' & $sTabHandle & '"}')
Sleep(1000)
_WD_Window($sSession, 'Switch' ,'{"handle":"' & $Handle & '"}')
Sleep(1000)
$Text = _WD_Alert($sSession, 'gettext')
_WD_Alert($sSession, 'accept')
MsgBox(0,'Test Alert Text',$Text)

My Console:

_WD_Alert: {"value":{"error":"no alert open","message":"(Session infochrome=64.0.3282.140)","stacktrace":"Backtrace:\n\t(No symbol) [0x0117C2F0]\n\t(No symbol) [0x0116473D]\n\t(No symbol) [0x01133D93]\n\t(No symbol) [0x0113045D]\n\t(No symbol) [0x010F3CA3]\n\t(No symbol) [0x01115B6A]\n\t(No symbol) [0x010F38F7]\n\t(No symbol) [0x011159FB]\n\t(No symbol) [0x011006B4]\n\t(No symbol) [0x01101C86]\n\t(No symbol) [0x01101C09]\n\tGetHandleVerifier [0x01196C37+62007]\n\t(No symbol) [0x01180453]\n\t(No symbol) [0x0114CF76]\n\t(No symbol) [0x0114D365]\n\t(No symbol) [0x0114D47E]\n\t(No symbol) [0x01182527]\n\t(No symbol) [0x0114CCBF]\n\t(No symbol) [0x0114DFBF]\n\t(No symbol) [0x01149D6B]\n\t(No symbol) [0x01149EC3]\n\t(No symbol) [0x0115BEB9]\n\tBaseThreadInitThunk [0x7703336A+18]\n\tRtlInitializeExceptionChain [0x77569882+99]\n\tRtlInitializeExceptionChain [0x77569855+54]\n"}}

 

[Danp2]

I see a few issues  --

1. This line is invalid

   $Handle = _WD_Window($sSession, 'handle', '')

   Change 'handle' to 'window' to retrieve the handle for the currently active window. 

2.  Using Chrome, the alert disappears when you switch tabs. This occurs even when you manually change tabs. You can test this yourself by hitting F12 to bring up the developer console and manually issuing the call to Alert. This doesn't occur with Firefox.

P.S. Next time post the full console output. ;-)

[Danp2]

@NguyenLe See discussion here for further explanation of Chrome behavior.

[NguyenLe]

@Danp2 If I change tabs, the alert still not disappear. And I test by hitting F12.

Thank for you answer.

Edited February 3, 2018 by NguyenLe

[Danp2]

@NguyenLe Yes, I see that from your post. But that's not how it behaves for me and not how it is designed to behave based upon the link I posted in #90 above.

What version of Chrome was you using? 32 or 64 bit? Anything else you can think of that would be affecting this (ie: Chrome setting or extension that would affect this)?

[NguyenLe]

My version of Chrome is 64 bit.

[Danp2]

What version is displayed under chrome://settings/help?

Edit: I just updated my Chrome to v64 and now I'm seeing where the alert isn't being removed when switching tabs. Let me rerun the code to see if I can duplicate the behavior you described.

Edited February 3, 2018 by Danp2

[NguyenLe]

My version of Chrome is 64.0.3282.119 (64 bit).

Edited February 3, 2018 by NguyenLe

[Danp2]

FYI, I'm seeing the same behavior as you. Unsure at this point, but I suspect that it may be an issue with the Chrome web driver. One way to test this would be to temporarity switch to using FireFox and then rerun your test code to see if the results are the same.

[NguyenLe]

I tested in Firefox. It run normal but it don't wait for loading the page.

How should I deal with this in Firefox?

The Problem: Checking your brower

 

Edited February 3, 2018 by NguyenLe

[Danp2]

@NguyenLe Sorry, but you can't just post an image and expect us to know what has occurred. 

Also, I went to this site in Chrome and encountered the same delay in the site loading. This appears to be by design; it is the DDos protection from Cloudflare. Since this occurs in a standard browser session, you can't expect the behavior to be different when using the Web Driver. 

There are likely ways to deal with this. One thought would be to write a function that loops for a defined period, retrieving the site's text and watching for the existence or non-existence of a provided text phrase. This could be a good "helper" function. Now someone just needs to write it. 

[NguyenLe]

8 minutes ago, Danp2 said:

@NguyenLe Sorry, but you can't just post an image and expect us to know what has occurred. 

Also, I went to this site in Chrome and encountered the same delay in the site loading. This appears to be by design; it is the DDos protection from Cloudflare. Since this occurs in a standard browser session, you can't expect the behavior to be different when using the Web Driver. 

There are likely ways to deal with this. One thought would be to write a function that loops for a defined period, retrieving the site's text and watching for the existence or non-existence of a provided text phrase. This could be a good "helper" function. Now someone just needs to write it. 

Ok, Thank you.

[NguyenLe]

I can not use the Click Element command in Firefox

My Code:

SetupGecko()
_WD_Startup()
$sSession = _WD_CreateSession($sDesiredCapabilities)
_WD_Navigate($sSession, 'http://google.com')
$sElement = _WD_FindElement($sSession,$_WD_LOCATOR_ByXPath,"//a[@class='gsfi']")
_WD_ElementAction($sSession, $sElement, 'value','Hello')

My Console:

_WDStartup: OS: WIN_7 WIN32_NT 7601 Service Pack 1
_WDStartup: AutoIt: 3.3.14.2
_WDStartup: WD.au3: 0.1.0.6
_WDStartup: Driver: geckodriver.exe
_WDStartup: Params: --log trace
_WDStartup: Port:   4444
__WD_Post: URL=HTTP://127.0.0.1:4444/session; $sData={"desiredCapabilities":{"javascriptEnabled":true,"nativeEvents":true,"acceptInsecureCerts":true}}
__WD_Post: StatusCode=200; ResponseText={"value": {"sessionId":"72ea7fca-2466-46cb-a334-5dbd8cdc7dba","capabilities":{"acceptInsecureCerts":true,"browserName":"firefox","browserVersion":"58.0.1","moz:accessibilityChecks":false,"moz:headless":false,"moz:processID":3708,"moz:profile":"C:\\Users\\PC\\AppData\\Local\\Temp\\rust_mozprofile.yhmYGIKQ7K6Z","moz:webdriverClick":true,"pageLoadStrategy":"normal","platformName":"windows_nt","platformVersion":"6.1","rotatable":false,"timeouts":{"implicit":0,"pageLoad":300000,"script":30000}}}}
_WD_CreateSession: {"value": {"sessionId":"72ea7fca-2466-46cb-a334-5dbd8cdc7dba","capabilities":{"acceptInsecureCerts":true,"browserName":"firefox","browserVersion":"58.0.1","moz:accessibilityChecks":false,"moz:headless":false,"moz:processID":3708,"moz:profile":"C:\\Users\\PC\\AppData\\Local\\Temp\\rust_mozprofile.yhmYGIKQ7K6Z","moz:webdriverClick":true,"pageLoadStrategy":"normal","platformName":"windows_nt","platformVersion":"6.1","rotatable":false,"timeouts":{"implicit":0,"pageLoad":300000,"script":30000}}}}
__WD_Post: URL=HTTP://127.0.0.1:4444/session/72ea7fca-2466-46cb-a334-5dbd8cdc7dba/url; $sData={"url":"http://google.com"}
__WD_Post: StatusCode=200; ResponseText={"value": {}}
_WD_Navigate: {"value": {}}
__WD_Post: URL=HTTP://127.0.0.1:4444/session/72ea7fca-2466-46cb-a334-5dbd8cdc7dba/element; $sData={"using":"xpath","value":"//a[@class='gsfi']"}
__WD_Post: StatusCode=404; ResponseText={"value":{"error":"no such element","message":"Unable to locate element: //a[@class='gsfi']","stacktrace":"stack backtrace:\n   0:           0x4821c4 - <no info>\n   1:           0x482933 - <no info>\n   2:           0x445159 - <no info>\n   3:           0x44eff6 - <no info>\n   4:           0x4322e1 - <no info>\n   5:           0x40ba4e - <no info>\n   6:           0x4119b9 - <no info>\n   7:           0x6d2c89 - <no info>\n   8:           0x426006 - <no info>\n   9:           0x6cd490 - <no info>\n  10:         0x77a75a4d - BaseThreadInitThunk"}}
_WD_FindElement: {"value":{"error":"no such element","message":"Unable to locate element: //a[@class='gsfi']","stacktrace":"stack backtrace:\n   0:           0x4821c4 - <no info>\n   1:           0x482933 - <no info>\n   2:           0x445159 - <no info>\n   3:           0x44eff6 - <no info>\n   4:           0x4322e1 - <no info>\n   5:           0x40ba4e - <no info>\n   6:           0x4119b9 - <no info>\n   7:           0x6d2c89 - <no info>\n   8:           0x426006 - <no info>\n   9:           0x6cd490 - <no info>\n  10:         0x77a75a4d - BaseThreadInitThunk"}}
_WD_FindElement ==> No match: no such element
__WD_Post: URL=HTTP://127.0.0.1:4444/session/72ea7fca-2466-46cb-a334-5dbd8cdc7dba/element//value; $sData={"id":"", "text":"Hello", "value":["H","e","l","l","o"]}
__WD_Post: StatusCode=404; ResponseText={"value":{"error":"unknown command","message":"POST /session/72ea7fca-2466-46cb-a334-5dbd8cdc7dba/element//value did not match a known command","stacktrace":"stack backtrace:\n   0:           0x4821c4 - <no info>\n   1:           0x482933 - <no info>\n   2:           0x445159 - <no info>\n   3:           0x43f00a - <no info>\n   4:           0x409e7b - <no info>\n   5:           0x41198a - <no info>\n   6:           0x6d2c89 - <no info>\n   7:           0x426245 - <no info>\n   8:           0x6cd490 - <no info>\n   9:         0x77a75a4d - BaseThreadInitThunk"}}
_WD_ElementAction: {"value":{"error":"unknown command","message":"POST /session/72ea7fca-2466-46cb-a334-5dbd8cdc7dba/element//value did not match a known command","stacktrace":"stack backtrace:\n   0:           0x4821c4 - <no info>\n   1:           0x482933 - <no info>\n   2:           0x445159 - <no info>\n   3:           0x43f00a - <no info>\n   4:           0x409e7b - <no info>\n   5:           0x41198a - <no info>\n   6:           0x6d2c89 - <no info>\n   7:           0x426245 - <no info>\n   8:           0x6cd490 - <no info>\n   9:         0x77a75a4d - BaseThreadInitThunk"}}

 

[Danp2]

11 minutes ago, NguyenLe said:

I can not use the Click Element command in Firefox

That's not the issue. 

11 minutes ago, NguyenLe said:

__WD_Post: URL=HTTP://127.0.0.1:4444/session/72ea7fca-2466-46cb-a334-5dbd8cdc7dba/element; $sData={"using":"xpath","value":"//a[@class='gsfi']"} __WD_Post: StatusCode=404; ResponseText={"value":{"error":"no such element","message":"Unable to locate element: //a[@class='gsfi']","stacktrace":"stack backtrace:\n   0:           0x4821c4 - <no info>\n   1:           0x482933 - <no info>\n   2:           0x445159 - <no info>\n   3:           0x44eff6 - <no info>\n   4:           0x4322e1 - <no info>\n   5:           0x40ba4e - <no info>\n   6:           0x4119b9 - <no info>\n   7:           0x6d2c89 - <no info>\n   8:           0x426006 - <no info>\n   9:           0x6cd490 - <no info>\n  10:         0x77a75a4d - BaseThreadInitThunk"}} _WD_FindElement: {"value":{"error":"no such element","message":"Unable to locate element: //a[@class='gsfi']","stacktrace":"stack backtrace:\n   0:           0x4821c4 - <no info>\n   1:           0x482933 - <no info>\n   2:           0x445159 - <no info>\n   3:           0x44eff6 - <no info>\n   4:           0x4322e1 - <no info>\n   5:           0x40ba4e - <no info>\n   6:           0x4119b9 - <no info>\n   7:           0x6d2c89 - <no info>\n   8:           0x426006 - <no info>\n   9:           0x6cd490 - <no info>\n  10:         0x77a75a4d - BaseThreadInitThunk"}} _WD_FindElement ==> No match: no such element

You can't click an element that wasn't found by the prior function call. You'll need to locate the element first. Also some error checking in your code would help you here as well.