Closed Bug 1337898 Opened 5 years ago Closed 3 years ago

Window manipulation command sequence causes hang

Categories

(Testing :: Marionette, defect, P3)

Version 3
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: jugglinmike, Unassigned)

References

Details

Attachments

(5 files)

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.
Attachment #8835033 - Attachment mime type: text/x-log → text/plain
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?
Flags: needinfo?(mike)
Attached file geckodriver-1337898.py
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/
Flags: needinfo?(mike)
(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.
Priority: -- → P3
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.
Flags: needinfo?(mike)
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/.
Flags: needinfo?(mike) → needinfo?(hskupin)
(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.
Flags: needinfo?(hskupin)
Summary: Command sequence causes Marionette to hang → Window manipulation command sequence causes hang
Depends on: 1492499
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.
Flags: needinfo?(mike)
> 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!
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(mike)
Resolution: --- → FIXED
Perfect! Thanks for letting us know.
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.