1337898 - Window manipulation command sequence causes hang

Status: RESOLVED WORKSFORME

(Remote Protocol :: Marionette, defect, P3)

Description

[Mike Pennisi [:jugglinmike]]

Attachment: 17.02.08-geckodriver-hang.log

The follow command sequence causes Marionette to hang:

1. Create a new window via "execute script"
2. Close the current window
3. Switch to the window created in (1)
4. Close the current window
5. Switch to the current top-level browsing context

I can reproduce this using GeckoDriver and both Firefox stable build (51.0.1)
and Nightly (54.0a1 - 2017-02-07) on x64 Linux. I've attached the relevant log
from GeckoDriver.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

So looking at the log you are trying to close all windows, which actually will cause Geckodriver to think that Firefox should be closed.

In the above case the test looks like:

> driver.close()
> driver.switchToFrame()

Did you have other windows open before step 1? If not don't you have the latest GeckoDriver installed?

Comment 2

[Mike Pennisi [:jugglinmike]]

Attachment: 1337898-geckodriver-output.txt

Comment 3

[Mike Pennisi [:jugglinmike]]

Attachment: 1337898-python-output.txt

Comment 4

[Mike Pennisi [:jugglinmike]]

Attachment: geckodriver-1337898.py

Comment 5

[Mike Pennisi [:jugglinmike]]

I was previously using GeckoDriver at version 0.13.0, but I now see that 0.14.0
has been released, with a promising note in the change log:

> Firefox process is now terminated and session ended when the last window is
> closed

Unfortunately, this does not seem to resolve the issue. There is no other
instance of Firefox Nightly running during this test. To be clear: I do not
have an actual use case for this sequence of commands. It seemed worth
reporting, though, because Marionette probably should not hang in any case.

I've included the relevant version information below, and I've attached a few
files:

- geckodriver-1337898.py: a reduced test case in Python whose only dependency
  is the "requests" library [1]
- 1337898-python-output.txt: the output from that process
- 1337898-geckodriver-output.txt: the associated output of GeckoDriver (as run
  with `--binary $(which firefox-nightly) --log debug`)

    $ firefox-nightly --version
    Mozilla Firefox 54.0a1

    $ ./downloads/geckodriver --version
    geckodriver 0.14.0

    The source code of this program is available at
    https://github.com/mozilla/geckodriver.

    This program is subject to the terms of the Mozilla Public License 2.0.
    You can obtain a copy of the license at https://mozilla.org/MPL/2.0/.

[1] http://python-requests.org/

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

(In reply to Mike Pennisi [:jugglinmike] from comment #5)
> > Firefox process is now terminated and session ended when the last window is
> > closed
> 
> Unfortunately, this does not seem to resolve the issue. There is no other

We still have problems with https://github.com/mozilla/geckodriver/issues/285. Maybe we should wait until bug 1337743 has been fixed.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Mike, would you mind trying again? A couple of months have been passed by, and the bug I was referring in comment 6 also got fixed a while ago. Thanks.

Comment 8

[Mike Pennisi [:jugglinmike]]

Hi Henrik, thanks for following up on this! Using Firefox 56.0 and GeckoDriver
0.19.1, I now see the call to "Get current window" returning an when it follows
the "delete window" command--even in though a child window had previously been
created. If I'm interpreting your feedback in comment 1 correctly, then this is
expected behavior. Can you confirm? If so, this bug is resolved.

    $ firefox --version
    Mozilla Firefox 56.0
    
    $ ./geckodriver --version
    geckodriver 0.19.1
    
    The source code of this program is available from
    testing/geckodriver in https://hg.mozilla.org/mozilla-central.
    
    This program is subject to the terms of the Mozilla Public License 2.0.
    You can obtain a copy of the license at https://mozilla.org/MPL/2.0/.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

(In reply to Mike Pennisi [:jugglinmike] from comment #8)
> 0.19.1, I now see the call to "Get current window" returning an when it follows
> the "delete window" command--even in though a child window had previously
> been created. 

There is at least one missing word for the response value of get current window. So I'm not sure what you are getting here. 

> If I'm interpreting your feedback in comment 1 correctly, then this is
> expected behavior. Can you confirm? If so, this bug is resolved.

If you close a window, and call get current window handle on it, then a NoSuchWindowError will be thrown, because the window is no longer present. 

In regards of your original steps in comment 0, Firefox should be closed with step 4, so any following commands should cause failures.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Mike, mind following up on my last comment, and maybe test those steps again with the most recently Nightly build of Firefox? When you have some code it might be good to also add it to the next comment. Thanks a lot.

Comment 11

[Mike Pennisi [:jugglinmike]]

Attachment: Revised steps to reproduce which now demonstrate the expected behavior

Comment 12

[Mike Pennisi [:jugglinmike]]

> When you have some code it might be good to also add it to the next comment.

See Comment 4 and Comment 5. Geckodriver is much more standards-compliant these
days (nice work!), so I had to modify it a bit.

> If you close a window, and call get current window handle on it, then a
> NoSuchWindowError will be thrown, because the window is no longer present.

This aligns with the behavior I'm seeing today.

> In regards of your original steps in comment 0, Firefox should be closed with
> step 4, so any following commands should cause failures.

This aligns with the behavior I'm seeing today.

I've uploaded the modified version of the script (comment 11), but only in case
that's interesting to anyone. This issue is resolved. Thanks!

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Perfect! Thanks for letting us know.