Remove the detection of Firefox if no binary has been specified

RESOLVED DUPLICATE of bug 703646

Status

Testing
Mozbase
RESOLVED DUPLICATE of bug 703646
7 years ago
7 years ago

People

(Reporter: whimboo, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
We are having code which tries to find existing Firefox installations. This list is kinda outdated and could even probably removed. At least the latter option has also been approved by Clint.

https://github.com/mozautomation/mozmill/blob/master/mozrunner/mozrunner/runner.py#L157
(Reporter)

Updated

7 years ago
Summary: Remove the detection of Firefox is no binary has been specified → Remove the detection of Firefox if no binary has been specified

Comment 1

7 years ago
I'm against the removal. If e.g. firefox is on the path, as it is for me, should i really have to specify it? Seems silly.  For linux and windows, its pretty straight-forward.  Its only mac where you have funky names in the usual cases

Updated

7 years ago
Depends on: 703646

Comment 2

7 years ago
We should probably document what we have first.  I am very content to live with defaulting to `which firefox` on linux and would hate to have this go away (since most of the time I would type, e.g. mozmill -b `which firefox` , which is mostly silly.  That said, it is overcomplicated and I think we should consider what we want to do from the light of what we do now.  Hence the dependency on bug 703646

Comment 3

7 years ago
I still think this should be removed.
(In reply to Jeff Hammel [:jhammel] from comment #2)
> We should probably document what we have first.  I am very content to live
> with defaulting to `which firefox` on linux

Just pointing out there's an os independent which function in mozharness we could use: http://mxr.mozilla.org/build/source/mozharness/mozharness/base/script.py#261

That being said I'm fine with either simplifying to 'which' or removing entirely.

Comment 5

7 years ago
(In reply to Andrew Halberstadt [:ahal] from comment #4)
> (In reply to Jeff Hammel [:jhammel] from comment #2)
> > We should probably document what we have first.  I am very content to live
> > with defaulting to `which firefox` on linux
> 
> Just pointing out there's an os independent which function in mozharness we
> could use:
> http://mxr.mozilla.org/build/source/mozharness/mozharness/base/script.py#261
> 
> That being said I'm fine with either simplifying to 'which' or removing
> entirely.

We also have this in mozrunner:

https://github.com/mozilla/mozbase/blob/master/mozrunner/mozrunner/utils.py#L87

It is sad that this is not in python core

Comment 6

7 years ago
(In reply to Jeff Hammel [:jhammel] from comment #5)
> (In reply to Andrew Halberstadt [:ahal] from comment #4)
> > (In reply to Jeff Hammel [:jhammel] from comment #2)
> > > We should probably document what we have first.  I am very content to live
> > > with defaulting to `which firefox` on linux
> > 
> > Just pointing out there's an os independent which function in mozharness we
> > could use:
> > http://mxr.mozilla.org/build/source/mozharness/mozharness/base/script.py#261
> > 
> > That being said I'm fine with either simplifying to 'which' or removing
> > entirely.
> 
> We also have this in mozrunner:
> 
> https://github.com/mozilla/mozbase/blob/master/mozrunner/mozrunner/utils.
> py#L87
> 
> It is sad that this is not in python core
This isn't going to help anyone on mac or windows though because no one on those OS's puts firefox in their path.  I think we should avoid having tricked out workflows on a per OS basis, because that just opens the gateway to differing behavior that then gets us right back into this mess later.  As I said on the other bug (not sure why these aren't dupes, but I haven't looked closely) that allowing people to point at the .app on mac is still valid because most people do not realize that the .app isn't a real object.  But, otherwise, unless there are exceptionally valid UX reasons to differentiate on a per platform basis, I'm against differentiating on a per platform basis.  I think that's how we opened this entire can of worms, and I'd much prefer to close it.

Comment 7

7 years ago
Most of the discussion and the patch happened on bug 703646 so marking as a duplicate of that
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 703646
You need to log in before you can comment on or make changes to this bug.