Closed
Bug 1337898
Opened 8 years ago
Closed 7 years ago
Window manipulation command sequence causes hang
Categories
(Remote Protocol :: Marionette, defect, P3)
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)
Reporter | ||
Comment 2•8 years ago
|
||
Reporter | ||
Comment 3•8 years ago
|
||
Reporter | ||
Comment 4•8 years ago
|
||
Reporter | ||
Comment 5•8 years ago
|
||
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.
Updated•8 years ago
|
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)
Reporter | ||
Comment 8•8 years ago
|
||
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)
Updated•7 years ago
|
Depends on: marionette-window-tracking
Updated•7 years ago
|
Summary: Command sequence causes Marionette to hang → Window manipulation command sequence causes hang
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)
Reporter | ||
Comment 11•7 years ago
|
||
Reporter | ||
Comment 12•7 years ago
|
||
> 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: 7 years ago
Flags: needinfo?(mike)
Resolution: --- → FIXED
Perfect! Thanks for letting us know.
Resolution: FIXED → WORKSFORME
Updated•2 years ago
|
Product: Testing → Remote Protocol
You need to log in
before you can comment on or make changes to this bug.
Description
•