Mutt tests - launching with bogus arg, launches binary with users' profile, no error msg

RESOLVED INVALID

Status

--
minor
RESOLVED INVALID
6 years ago
2 years ago

People

(Reporter: jfrench, Unassigned)

Tracking

Details

(URL)

(Reporter)

Description

6 years ago
At least on Windows, launching Mutt with a bogus command line argument

a) launches the binary instead of providing an error, or the usage message
b) launches the binary not with a clean insulated user profile, but with the user's personal system profile.

eg.
mutt -x bogus/argument -b "C:\Program Files\Mozilla Firefox Default\firefox.exe"
Usually the command line parser spit out a failure message. Would be nice if we can get this fixed.
Component: Mozmill Tests → Mozmill
Product: Mozilla QA → Testing
Whiteboard: [mentor=whimboo][lang=python][good first bug]

Comment 2

6 years ago
Hello,

I would like to fix this bug.How can I get start with it?
Hm, we shouldn't setup mentored bugs for bugs which haven't been confirmed yet. Jonathan, are you still seeing this behavior on Windows with latest tip? I cannot reproduce it on Linux. In my case I get a valid failure message in the terminal.
(Reporter)

Comment 4

6 years ago
On Windows in a mozmill-env 2.0 shell I now get the correct error:

mutt-script.py: error: no such option: -x

On Windows in mozilla-build shell, sourced to venv/Scripts/activate in a 2.0 master branch, I get the bug behaviour. But given that the 2nd method (running in a virtual environment, and/or within a mozilla-build shell) probably isn't a sanctioned way of running 2.0, I favour marking the bug resolved invalid or worksforme.
Not sure what 'venv/Scripts/activate' is but given that it sounds strange and everything works as expected via the mozmill-2.0 environment, lets mark this bug as invalid. I never have seen this before, so most likely it's a bad combination of several virtual environments.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
Whiteboard: [mentor=whimboo][lang=python][good first bug]
(Reporter)

Comment 6

6 years ago
venv/Scripts/activate is the windows equivalent for enabling a virtual environment prior to setup_development.py, described on Github only for unix
https://github.com/mozilla/mozmill/blob/master/README.md

git clone git://github.com/mozilla/mozmill.git
cd mozmill
virtualenv venv
source venv/bin/activate <- ** (on windows this is venv/Scripts/activate)
./setup_development.py

But I agree, the use of that virtual environment here, is not required since mozmill-env shell accomplishes what is needed, while also producing the desired error.
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.