Not found error when clicking, but click is performed #153

Closed
molily opened this Issue Jun 21, 2012 · 17 comments

Comments

Projects
None yet
2 participants
Contributor

molily commented Jun 21, 2012

I’m using the latest master (since 0.6.10 doesn’t seem to regard my test --includes, but that seems to be fixed in master.)

I have something like this:

casper.then ->
  @test.assertExists '#login .decline', 'should have a decline button'
  @captureSelector 'screenshots/login-decline.png', '#login .decline'
  # Close the login view
  @click '#login .decline'

casper.then ->
  @echo 'after click', 'INFO'
  @captureSelector 'screenshots/login-decline-clicked.png', 'body'
  @test.assertDoesntExist '#login', 'should not show the login overlay'

Everything works fine: The button is found, the first test passes, the screenshot shows the button correctly. Also, the button is actually clicked, its JS handler is called, the second screenshot is fine, the second test passes.

Except that @click() raises an error message which says the button doesn’t exist:


PASS should have a decline button
[remote] LoginView#declineButtonHandler
[error] [phantom] Couldn't emulate 'click' event on #login .decline: CasperError: No element matching selector found: #login .decline
after click
PASS should not show the login overlay

It’s not a failing test but a misleading error message in my log.

I tried to debug the Casper code a bit but didn’t found the cause myself.

The cause might be that the button is removed from DOM right after the click. I’m assuming Casper tries to access it twice when clicking it. The first time it’s in the DOM, the second time it’s already removed.

Owner

n1k0 commented Jun 21, 2012

Very hard to investigate without having access to the website you're testing and the real code.

Contributor

molily commented Jun 22, 2012

I will post a working test against the live site soon.

Contributor

molily commented Jun 22, 2012

Owner

n1k0 commented Jun 22, 2012

This is weird because as soon the login overlay is loaded, it looks like its contents are removed from the container. I think there are some javascript voodoo behind the code of this page, but I don't have much time for this kind of specific investigations…

Contributor

molily commented Jun 22, 2012

As I said, the overlay is removed from the DOM when the decline button is clicked. This is the behavior the spec is supposed to test, and the test passes except for the error message. There’s no voodoo, the element is not removed from DOM before, as the test proves.

Contributor

molily commented Jun 22, 2012

I’ll make a simpler example to reproduce this in a cleaner environment without dependencies.

Owner

n1k0 commented Jun 22, 2012

So please try to reproduce a more simple, illustrative test case. I have definitely not the time to dig into specific website implementation problems, sorry.

Owner

n1k0 commented Jun 22, 2012

I’ll make a simpler example to reproduce this in a cleaner environment without dependencies.

Deal! (sorry, we posted at the same time)

Contributor

molily commented Jun 22, 2012

;-) No problem

n1k0 was assigned Jun 29, 2012

Owner

n1k0 commented Jun 29, 2012

Poke :)

Owner

n1k0 commented Jul 2, 2012

Poke? :/

Contributor

molily commented Jul 2, 2012

Sorry, I didn’t have time the last weeks, but I haven’t forgotten it and will surely come back to provide a testcase.

Owner

n1k0 commented Jul 2, 2012

Great :)

Contributor

molily commented Jul 4, 2012

This is a minimal testcase:
https://gist.github.com/3046701

I think the point here is using a elements and preventDefault, plus removing the parent from the DOM on click. The error message isn’t shown if the button is a button or span element, for example.

Contributor

molily commented Jul 4, 2012

I’m using the latest master together with PhantomJS 1.6.0.

Owner

n1k0 commented Jul 5, 2012

Now my turn being busy :'(

I'll give it a look next week!

n1k0 closed this in 39b5e4c Jul 8, 2012

Owner

n1k0 commented Jul 8, 2012

Thanks for the report, there was indeed a problem with the dispatched event result when preventDefault() is used. It's now fixed. I just hope it won't too much break BC for existing scripts which were possibly relying on the previous (broken) behavior :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment