Closed
Bug 241532
Opened 21 years ago
Closed 18 years ago
Ensure that Firefox can be easily deployed at 1.0
Categories
(Firefox :: General, defect, P1)
Firefox
General
Tracking
()
RESOLVED
WORKSFORME
Firefox1.0beta
People
(Reporter: mconnor, Assigned: chofmann)
References
(Depends on 1 open bug)
Details
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•21 years ago
|
Comment 1•20 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.
Reporter | ||
Comment 3•20 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•20 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
Comment 5•20 years ago
|
||
yes, it'd be great if we could look into offering an MSI installer. this is a
popular enterprise request AFAIK.
Comment 6•20 years ago
|
||
Volunteers are all over the MSI installer: see bug 231062, which I'm marking as
a dependency.
/be
Comment 7•20 years ago
|
||
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.
Comment 8•20 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.
Comment 9•20 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•18 years ago
|
QA Contact: general
Comment 10•18 years ago
|
||
Firefox is now at v2 and climbing - I think this bug needs re-evaluating...
Comment 11•18 years ago
|
||
Just another demonstration of the value of meta bugs...
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•