Crash when switching "back" from frame

[tompi]

Using serenity and ghostdriver on windows, and tried both remote driver and phantomjs, on both 1.9.8 and 2.0. Did not find a way to analyze dmp files on windows, so attaching them here(wiki only describes linux and osx, did I miss something?).

This seems to happen ALMOST always when I switch back from an iframe in which I click a button which reloads the frame.

Selenium code:
page.getDriver().switchTo().frame("contractSign");
page.getCancelSigningLink().click();
page.getDriver().switchTo().defaultContent();

https://drive.google.com/file/d/0B9h87jWLC5NFTGhpT2xMZWEyWlU/view?usp=sharing
https://drive.google.com/file/d/0B9h87jWLC5NFMVBDcEVWNlB6YlE/view?usp=sharing

Hope you can shed some light one the situation, I only found some old similar cases which was reported as solved in 2013...

Found a dirty workaround: do the work(clicking link) with client side javascript wrapped in a setTimeout, and then switching out of the iframe BEFORE setTimeout fires. Then everything works...

[zackw]

We apologize for not responding to this bug report sooner.

In order to do anything about this we need a complete, self-contained, minimal test case. That means: a set of HTML files, each of which has been made as small as possible, together with a PhantomJS controller script, also as small as possible; running the controller script against the HTML reproduces the bug. If at all possible, reproduce the problem without using Selenium. If the bug goes away when Selenium is removed from the equation, that is valuable information in itself.

(I have a nasty suspicion that your "dirty workaround" indicates that the problem is with selenium...)

Please note that 1.9.x is full of crasher bugs and is no longer maintained. Any fix for this bug will only be applied to 2.0.

Please also be aware that dmp files are basically useless to us - we usually can't get a meaningful stack trace out of them, and even when we do, it often doesn't tell us anything we didn't already know (e.g. "yeah, that's crashing somewhere inside Webkit"). The test case is enormously more valuable.

[spleshka]

I've got the similar issue on phantomjs-2.0.1. Quick steps to reproduce:

• Create a new iframe
• Switch to this iframe
• Click a button inside of the iframe which closes or reloads the iframe
• Switch out of the iframe - phantomjs crashes

We use codeception + webdriver + phantomjs. The same steps work fine if we switch from phantomjs to selenium server, that's why I believe that the issue is at the phantomjs end.

I'll provide a minimal test case soon.

[spleshka]

Here is the test case:

• Main phantomjs.html file which has a link to create/open a new iframe: https://gist.github.com/spleshka/e4766a03115a1b3a5334
• File with iframe phantomjs-iframe.html: https://gist.github.com/spleshka/07a52d46104d0fed9b19
• Example test case:

  public function testIframe(AcceptanceTester $I) {
    $I->amOnPage('/phantomjs.html');
    $I->click('a#open-iframe');
    $I->switchToIFrame('demo-iframe');
    $I->click('a#close-iframe');
    $I->switchToIFrame(); // Causes crash.
  }

As I've already mentioned - the test case above works fine on selenium server, but unfortunately fails on phantomjs. I'd appreciate any feedback on this issue. Thanks.

[spleshka]

Hey guys, any updates about this issue? The problem is still relevant, and we can't use phantomjs on our projects because of this issue.

[wernight]

Had similar going to PayPal and back. I don't see the 2.0.1 release tag.

[vurral]

Can reproduce the same error as @spleshka on 2.0.1.

I made a gist with a complete test case: https://gist.github.com/kramsee/84c859858cb4dbfaae15

If there is more I can do, let me know!

[zackw]

@kramsee Thank you for the complete and minimal test case. There's just one more thing I'd like to ask you to do, if possible: write a second controller script that doesn't use WebDriver/Selenium. That is, see if you can reproduce the crash using the native PhantomJS API. It's going to look something like this:

var page = require('webpage').create();
page.open("http://localhost:8000/phantomjs.html", function () {
    page.evaluate(function () { document.getElementById("#open-iframe").click(); });
    page.switchToFrame("demo-iframe");
    page.evaluate(function () { document.getElementById("#close-iframe").click(); });
    page.switchToMainFrame();
    phantom.exit(0);
});

but you may need to tweak it a bit to make it do exactly the same thing as the Selenium script. The reason I'm asking you to do this is Selenium mode adds a huge glob of complexity and we'd like to know whether that has anything to do with the problem.

[wernight]

Do you mean HEAD as being 2.0.1? Because there is no such tag or release. Is HEAD stable?

[zackw]

@wernight I don't know what other people meant, but: There is no tag yet, but HEAD is currently being prepared for a release (originally announced as 2.0.1, but I think we're calling it 2.1 now) and should be stable enough for most uses -- the remaining things we need to solve before the release have mostly to do with generating the 'official' binaries.

[vurral]

@wernight Sorry, I was referring to the fork of Skakri, which is a build implementing a fix for file upload. That's due in 2.0.1 and that's why everyone refers to it like this (I guess).

@zackw I have added another file to my previous gist iframe-error.js implementing the same test case without selenium. I used your suggested code, but had to add two setTimeouts to handle the async parts of the test case. I don't know how much it affect the test case, but with this script phantomjs crashes ~7 out of 10 times.

[vurral]

@zackw Can I do something more to help tracking the bug further down?

[zackw]

@kramsee No, I think we have everything we need at this point; someone just needs to sit down and debug it.

(It's conceivable that pull request #12109 would fix this. I may test that later today if I get time.)

[zackw]

#12109 is not sufficient to fix this bug, alas.

[zackw]

A refinement of #12109 is sufficient to fix this bug. The fix will be in 2.1.

[vurral]

Awesome! Thank you very much @zackw!