Closed Bug 965183 Opened 10 years ago Closed 10 years ago

[mozrunner] --interactive mode is broken

Categories

(Testing :: Mozbase, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: andrei, Assigned: whimboo)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Running mozmill with --manual currently fails:

> (mozmill)sl77-212:964318 andrei.eftimie$ mozmill -b /Applications/FirefoxNightly.app/ --manual
> Traceback (most recent call last):
>   File "/Users/andrei.eftimie/work/mozilla/mozmill/bin/mozmill", line 8, in <module>
>     load_entry_point('mozmill==2.1-dev', 'console_scripts', 'mozmill')()
>   File "/Users/andrei.eftimie/work/mozilla/mozmill/src/mozmill/mozmill/__init__.py", line 812, in cli
>     CLI(args).run()
>   File "/Users/andrei.eftimie/work/mozilla/mozmill/src/mozmill/mozmill/__init__.py", line 785, in run
>     mozmill.runner.wait()
>   File "/Users/andrei.eftimie/work/mozilla/mozbase/src/mozrunner/mozrunner/base.py", line 106, in wait
>     self.returncode = self.process_handler.wait(timeout)
> TypeError: wait() takes exactly 1 argument (2 given)

This works correctly with mozmill 2.0.3
Andrei, are you sure that you have mozrunner 5.31 installed? Looks like something is wrong with your setup here. Also you are running with mozmill version 2.1-dev and not on hotfix-2.0.
Flags: needinfo?(andrei.eftimie)
Ok, so I can only see this on OS X but not on Linux nor Windows. The failure appears a couple of seconds after Firefox has been opened. This is actually a mozrunner bug and caused by my refactoring on bug 960084.
Assignee: nobody → hskupin
No longer blocks: 960495
Status: NEW → ASSIGNED
OS: All → Mac OS X
Blocks: 960084, 960495
Component: Mozmill → Mozbase
Flags: needinfo?(andrei.eftimie) → in-testsuite?
Keywords: regression
Summary: --manual mode is broken → [mozrunner] --interactive mode is broken
So we actually have at least two issues here. The one as mentioned above and if you are trying to stop the application:

Exception TypeError: "kill() got an unexpected keyword argument 'sig'" in <bound method FirefoxRunner.__del__ of <mozrunner.local.FirefoxRunner object at 0x107584dd0>> ignored

That failure was already existent before my refactoring but we never noticed. I have seen this now while working on a test. So I will fix both and others if more appear.
Attached patch Patch v1 (obsolete) — Splinter Review
Fix for mozrunner's interactive mode and two more tests for the broken methods. This patch has been tested on OS X so far. While it's waiting for review I will the tests on Windows and Linux.
Attachment #8367324 - Flags: review?(ahalberstadt)
Comment on attachment 8367324 [details] [diff] [review]
Patch v1

Review of attachment 8367324 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, lgtm.

::: mozrunner/mozrunner/base.py
@@ +98,5 @@
>  
>          """
>          if self.is_running():
> +            # The interactive mode uses directly a Popen process instance. It's
> +            # wait() method doesn't have any parameters. So handle it separately.

I don't think this comment is necessary, the isinstance call tells us the same thing.

@@ +135,5 @@
>          if not self.is_running():
>              return
>  
> +        # The interactive mode uses directly a Popen process instance. It's
> +        # kill() method doesn't have any parameters. So handle it separately.

Same.
Attachment #8367324 - Flags: review?(ahalberstadt) → review+
The tests are passing on Linux and Windows and interactive mode works fine there.
(In reply to Andrew Halberstadt [:ahal] from comment #5)
> >          if self.is_running():
> > +            # The interactive mode uses directly a Popen process instance. It's
> > +            # wait() method doesn't have any parameters. So handle it separately.
> 
> I don't think this comment is necessary, the isinstance call tells us the
> same thing.

Well, I removed that if condition because it was not that clear to me. By just looking at the code you could also assume that kill() for Popen() has a timeout value but which defaults to None, so it waits forever. I think it is better to be explicit here. Shall I still remove those lines?
I guess it doesn't matter, you can leave it if you want.
Attached patch Patch v1.1Splinter Review
While applying the patch git announced a white-space issue which I have fixed in this version.
Attachment #8367324 - Attachment is obsolete: true
Attachment #8367339 - Flags: review+
https://github.com/mozilla/mozbase/commit/ec1fbe23a3041654739bd02b731aa17d954ba91e (master)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: