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



6 years ago
2 years ago


(Reporter: jfrench, Unassigned)






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.

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

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.

Comment 4

6 years ago
On Windows in a mozmill-env 2.0 shell I now get the correct error: 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.
Last Resolved: 6 years ago
Resolution: --- → INVALID
Whiteboard: [mentor=whimboo][lang=python][good first bug]

Comment 6

6 years ago
venv/Scripts/activate is the windows equivalent for enabling a virtual environment prior to, described on Github only for unix

git clone git://
cd mozmill
virtualenv venv
source venv/bin/activate <- ** (on windows this is venv/Scripts/activate)

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.