search

fhoeben / hsac-xebium-bridge

Bridge between HSAC's FitNesse fixtures and Xebia's Xebium
Apache License 2.0
1 stars 0 forks source link

typeOn needs JavaScript support? #7

Closed sglebs closed 7 years ago

sglebs commented 9 years ago

Hi @fhoeben

I am trying this with the bridge:

ensure  do  type    on  /AXWindow/AXGroup   with    33*2=

running this test results in these calls:

127.0.0.1 - - [24/Jun/2015 09:15:45] "POST /wd/hub/session HTTP/1.1" 200 88
127.0.0.1 - - [24/Jun/2015 09:15:46] "POST /wd/hub/session/1435148145893/timeouts HTTP/1.1" 200 57
127.0.0.1 - - [24/Jun/2015 09:15:46] "POST /wd/hub/session/1435148145893/timeouts/async_script HTTP/1.1" 200 57
127.0.0.1 - - [24/Jun/2015 09:15:46] "GET /wd/hub/session/1435148145893/window_handles HTTP/1.1" 200 63
127.0.0.1 - - [24/Jun/2015 09:15:46] "GET /wd/hub/session/1435148145893/window_handle HTTP/1.1" 200 61
127.0.0.1 - - [24/Jun/2015 09:15:46] "POST /wd/hub/session/1435148145893/timeouts HTTP/1.1" 200 57
127.0.0.1 - - [24/Jun/2015 09:15:46] "POST /wd/hub/session/1435148145893/timeouts/async_script HTTP/1.1" 200 57
127.0.0.1 - - [24/Jun/2015 09:15:59] "POST /wd/hub/session/1435148145893/elements HTTP/1.1" 200 78
127.0.0.1 - - [24/Jun/2015 09:16:10] "GET /wd/hub/session/1435148145893/element/_NS%253A429/displayed HTTP/1.1" 200 56
127.0.0.1 - - [24/Jun/2015 09:16:10] "POST /wd/hub/session/1435148145893/execute HTTP/1.1" 200 56
127.0.0.1 - - [24/Jun/2015 09:16:14] "GET /wd/hub/session/1435148145893/element/_NS%253A429/displayed HTTP/1.1" 200 56
127.0.0.1 - - [24/Jun/2015 09:16:14] "DELETE /wd/hub/session/1435148145893/cookie HTTP/1.1" 200 53
127.0.0.1 - - [24/Jun/2015 09:16:14] "POST /wd/hub/session/1435148145893/execute HTTP/1.1" 200 56
127.0.0.1 - - [24/Jun/2015 09:16:14] "DELETE /wd/hub/session/1435148145893 HTTP/1.1" 200 53

Why does it keep calling displayed? I return True and even then hsac asks to run this script:

POST /wd/hub/session/1435148145893/execute HTTP/1.1
Content-Type: application/json; charset=utf-8
Content-Length: 450
Host: localhost:5555
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.3.5 (java 1.5)
Accept-Encoding: gzip,deflate

{"script":"if (arguments[0].getBoundingClientRect) {\nvar rect \u003d arguments[0].getBoundingClientRect();\nreturn (\n  rect.top \u003e\u003d 0 \u0026\u0026\n  rect.left \u003e\u003d 0 \u0026\u0026\n  rect.bottom \u003c\u003d (window.innerHeight || document.documentElement.clientHeight) \u0026\u0026\n  rect.right \u003c\u003d (window.innerWidth || document.documentElement.clientWidth));\n} else { return null; }","args":[{"ELEMENT":"_NS%3A429"}]}

I always return null in my web driver when the client-side asks me tu run JavaScript. What happens is that hsac then bombs:

__EXCEPTION__:java.lang.NullPointerException
    at com.xebia.incubator.xebium.SeleniumDriverFixture.executeDoCommand(SeleniumDriverFixture.java:463) [xebium-0.15-SNAPSHOT-mqm.jar]
    at com.xebia.incubator.xebium.SeleniumDriverFixture.doOnWith(SeleniumDriverFixture.java:358) [xebium-0.15-SNAPSHOT-mqm.jar]
    at nl.hsac.fitnesse.fixture.slim.web.xebium.HsacSeleniumDriverFixture.doOnWith(HsacSeleniumDriverFixture.java:57) [hsac-xebium-bridge-0.1-SNAPSHOT.jar]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_40]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_40]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_40]
    at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_40]
    at fitnesse.slim.fixtureInteraction.DefaultInteraction.methodInvoke(DefaultInteraction.java:80) [fitnesse-standalone.jar]
    at fitnesse.slim.MethodExecutor.callMethod(MethodExecutor.java:44) [fitnesse-standalone.jar]
    at fitnesse.slim.MethodExecutor.invokeMethod(MethodExecutor.java:31) [fitnesse-standalone.jar]
    at fitnesse.slim.MethodExecutor.findAndInvoke(MethodExecutor.java:57) [fitnesse-standalone.jar]
    at fitnesse.slim.FixtureMethodExecutor.execute(FixtureMethodExecutor.java:20) [fitnesse-standalone.jar]
    at fitnesse.slim.StatementExecutor.getMethodExecutionResult(StatementExecutor.java:126) [fitnesse-standalone.jar]
    at fitnesse.slim.StatementExecutor.call(StatementExecutor.java:104) [fitnesse-standalone.jar]
    at fitnesse.slim.instructions.CallInstruction.executeInternal(CallInstruction.java:35) [fitnesse-standalone.jar]
    at fitnesse.slim.instructions.Instruction.execute(Instruction.java:29) [fitnesse-standalone.jar]
    at fitnesse.slim.ListExecutor$Executive.executeStatement(ListExecutor.java:49) [fitnesse-standalone.jar]
    at fitnesse.slim.ListExecutor$Executive.executeStatements(ListExecutor.java:43) [fitnesse-standalone.jar]
    at fitnesse.slim.ListExecutor.execute(ListExecutor.java:83) [fitnesse-standalone.jar]
    at fitnesse.slim.SlimServer.executeInstructions(SlimServer.java:84) [fitnesse-standalone.jar]
    at fitnesse.slim.SlimServer.processOneSetOfInstructions(SlimServer.java:77) [fitnesse-standalone.jar]
    at fitnesse.slim.SlimServer.tryProcessInstructions(SlimServer.java:56) [fitnesse-standalone.jar]
    at fitnesse.slim.SlimServer.serve(SlimServer.java:42) [fitnesse-standalone.jar]
    at fitnesse.slim.SlimService.handle(SlimService.java:186) [fitnesse-standalone.jar]
    at fitnesse.slim.SlimService.acceptOne(SlimService.java:194) [fitnesse-standalone.jar]
    at fitnesse.slim.SlimService.accept(SlimService.java:156) [fitnesse-standalone.jar]
    at fitnesse.slim.SlimService.startWithFactory(SlimService.java:77) [fitnesse-standalone.jar]
    at fitnesse.slim.SlimService.main(SlimService.java:57) [fitnesse-standalone.jar]

We could say that is is Xebium that is bombing, right? Well, when I try Xebium directly I do not have this issue:

127.0.0.1 - - [24/Jun/2015 09:28:55] "POST /wd/hub/session HTTP/1.1" 200 88
127.0.0.1 - - [24/Jun/2015 09:28:55] "GET /wd/hub/session/1435148935348/window_handle HTTP/1.1" 200 61
127.0.0.1 - - [24/Jun/2015 09:28:55] "POST /wd/hub/session/1435148935348/timeouts/async_script HTTP/1.1" 200 57
127.0.0.1 - - [24/Jun/2015 09:28:55] "POST /wd/hub/session/1435148935348/timeouts HTTP/1.1" 200 57
127.0.0.1 - - [24/Jun/2015 09:28:55] "POST /wd/hub/session/1435148935348/element HTTP/1.1" 200 76
127.0.0.1 - - [24/Jun/2015 09:28:55] "POST /wd/hub/session/1435148935348/execute HTTP/1.1" 200 56
127.0.0.1 - - [24/Jun/2015 09:28:55] "POST /wd/hub/session/1435148935348/element HTTP/1.1" 200 76
127.0.0.1 - - [24/Jun/2015 09:28:55] "GET /wd/hub/session/1435148935348/element/_NS%253A429/name HTTP/1.1" 200 61
127.0.0.1 - - [24/Jun/2015 09:28:55] "GET /wd/hub/session/1435148935348/element/_NS%253A429/attribute/type HTTP/1.1" 200 59
127.0.0.1 - - [24/Jun/2015 09:28:56] "POST /wd/hub/session/1435148935348/element/_NS%253A429/value HTTP/1.1" 200 56
127.0.0.1 - - [24/Jun/2015 09:28:56] "GET /wd/hub/session/1435148935348/element/_NS%253A429/name HTTP/1.1" 200 61
127.0.0.1 - - [24/Jun/2015 09:28:56] "DELETE /wd/hub/session/1435148935348 HTTP/1.1" 200 53

Any suggestions? Thanks!

fhoeben commented 9 years ago

The Javascript you see is checking whether the element to type on is actually on screen, or requires scrolling to first. I'm suprised by the nullpointer in Xebium. I can maybe look into that further tomorrow.

You are using your own webdriver right, so I expect you want none of this added functionality? Have you tried this with the 'basic' webium-selenium fixture? (I've updated the projects README to mention the 'basic' driver and the 'standard' one to explain the difference between the two)

P.S. What I did for ios-driver to be able use xpaths with browsertest is not caring about exceptions thrown when executing JavaScript. Can you try what happens when your driver throws an exception rather than return null?

sglebs commented 9 years ago

You mean you updated the Readme that shows at https://github.com/fhoeben/hsac-xebium-bridge ?

fhoeben commented 9 years ago

That was the readme I meant