Ensure that Firefox can be easily deployed at 1.0

RESOLVED WORKSFORME

Status

()

Firefox
General
P1
normal
RESOLVED WORKSFORME
14 years ago
6 years ago

People

(Reporter: mconnor, Assigned: chris hofmann)

Tracking

(Depends on: 2 bugs)

unspecified
Firefox1.0beta
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
Firefox 1.0 is in a few months, and we're missing some pieces to make
deployments of the browser really feasible/manageable.  Not sure how much of
this is also present/needed in Thunderbird either, we can morph this if needed.

- autoconfig is currently broken if LDAP isn't built. (bug 240897)
- we don't have any support for locked prefs when doing disabling (bug 241526)
- we don't have any official documentation/tools for sysadmins to use autoconfig
and ben's upcoming extension manager command-line installations (needed for
global installations of extensions)  (sort of bug 226876, but more specific to
the implementation end)
- we don't have an MSI package available, especially needed for Active Directory
deployments (bug 231062)  this is a major blocker for breaking into that space
- there's no way of dynamically limiting UI etc post-deployment (i.e. hiding
Bookmarks after the fact) since we're effectively limited to using
userChrome.css in the defaults/base/chrome directory.  Not sure what the best
solution to this one is.  (global version of userChrome.css?  probably needs a
spinoff for discussion)

Of course, I'm not directly dealing with the people doing deployments, so I'm
not sure how critical this is to major customers, but it seems like a major
issue in mid-level (100-1000) deployments based on feedback in forums/bugs/IRC.

This is something that I feel we can't miss for 1.0 and I'm willing to drive the
bus myself on this, but feedback is good as to how important this is perceived
to be and what I might be missing.
(Reporter)

Updated

14 years ago
Status: NEW → ASSIGNED
Depends on: 241534
Priority: -- → P1
Target Milestone: --- → Firefox1.0beta
Depends on: 229706

Updated

14 years ago
Depends on: 218944

Comment 1

14 years ago
Sorry bout the spam, added 218944 as a dependant. Important for windows based
networks, within Active Directory style rollouts windows proxy settings can be
set with one of the supplied adm files.
Chofmann, are you tracking this one?

/be
Flags: blocking-aviary1.0+
(Reporter)

Comment 3

13 years ago
dump to nobody, its a tracker, and I'm not going to have time to do anything
much with this.
Assignee: mconnor → nobody
Status: ASSIGNED → NEW
(Assignee)

Comment 4

13 years ago
going to try and get granrose to look at the msi installer, depending on time. 
ammer might be building docs on autoconfig...  
Assignee: nobody → chofmann
yes, it'd be great if we could look into offering an MSI installer.  this is a
popular enterprise request AFAIK.
Volunteers are all over the MSI installer: see bug 231062, which I'm marking as
a dependency.

/be
If we're going to promote MSI-based installs, we need to make sure that our
app-update mechanism can gracefully handle the case of an app installed via MSI
(including the user not having admin rights), that we can push extensions and
XPI-patches via MSI, etc.

It'd be awesome to do, though.

Updated

13 years ago
Depends on: 233625

Comment 8

13 years ago
I've made a MSI file at http://www.webheat.co.uk/firefox.php that almost does
everything an automated install needs to.
The only think I can't *easily* get it to do is assign itself as the default
browser, the reason for this is that the regkey strings that are checked when
firefox starts are checked in a case sensitive fashion.
I could put in absolute paths but then if anyone wants to install to a different
location the regkey's values will be wrong.

Updated

13 years ago
No longer depends on: 233625

Comment 9

13 years ago
I'm not sure what we're going to get here for 1.0 but based on what shaver
mentioned in comment #7, complete and functional msi doesnt seem like it's going
to be done by the time we ship 1.0. 

Maybe we've got a shot at some msi packaged build in bug 231062 and the problem
at bug 230462 looks fixed already, but at least a couple of the others have been
minused and the documentation bugs don't seem to have gone anywhere. 

I think this is a small enough group of tasks that we're better served at this
point by trying to get specific progress on the depends bugs rather than this
metabug. 
Flags: blocking-aviary1.0+ → blocking-aviary1.0-

Updated

13 years ago
Depends on: 271208

Updated

13 years ago
Depends on: 271214
(Reporter)

Updated

13 years ago
Depends on: 295065
QA Contact: general

Comment 10

11 years ago
Firefox is now at v2 and climbing - I think this bug needs re-evaluating...
Just another demonstration of the value of meta bugs...
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
No longer depends on: 231062
You need to log in before you can comment on or make changes to this bug.