Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 447535 - RHEL 5.2 beta / upstream Firefox 3 beta 5 autoConfig broken
Summary: RHEL 5.2 beta / upstream Firefox 3 beta 5 autoConfig broken
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: firefox
Version: 5.2
Hardware: All
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: Jonathan Blandford
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 447546 455794
TreeView+ depends on / blocked
 
Reported: 2008-05-20 13:25 UTC by Alan Matsuoka
Modified: 2018-10-19 21:03 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-28 13:24:37 UTC


Attachments (Terms of Use)

Description Alan Matsuoka 2008-05-20 13:25:26 UTC
Description of problem:

Most desktop Linux sites use the centralized configuration capabilities in
Firefox and other Mozilla projects.  Autoconfiguration is broken in upstream
Firefox 3 beta 5 and RHEL 5.2 beta but fixed in Firefox 3 trunk.

The patch is trivial and included in the customer reference URL above.  Or here:

https://bugzilla.mozilla.org/show_bug.cgi?id=427927

Any chance this patch can get pulled in by Red Hat prior to RHEL 5.2 release
next week?  A lot of sites are going to scream if you don't.

How reproducible:

100%

Steps to Reproduce:

Enable autoconfiguration for Firefox.  If you really need our whole setup, let
me know - this is a basic re-enablement issue from a bug.

Actual results:

No autoconfiguration.

Expected results:

Autocnfiguration works.

Additional info:

The impact to us is that we can't roll that verison of Firefox out -
autoconfiguration is an important part of our Firefox setup.  We'd either need
to apply the patch ourselves and build our own packages or wait for Red Hat to
get us something, both of which we've done before.

FWIW, that impact is the same under RHEL 4.7 as well.

If it's too late to get it in, we can take a hot fix or errata w/ debuginfo - I
was hoping if I let you know quickly enough after we figured this out that you
might be able to make the 5.2 and 4.7 releases right so that your support
organization doesn't get hit by this issue.  Any midsized or larger desktop
Linux deployment is going to use Firefox autoconfiguration.

Comment 4 Andreas Haupt 2008-07-03 12:58:44 UTC
Unfortunately even with the final 3.0 version (firefox-3.0-2.el5) autoconfig is
broken. Looks like there are some issues with the use of xulrunner.

I needed to create a link

/usr/lib/firefox-3.0/defaults/autoconfig ->
/usr/lib/xulrunner-1.9/defaults/autoconfig/

to get autoconfig working. Firefox wrongly assumes some files in
/usr/lib/firefox-3.0/defaults/autoconfig which are in
/usr/lib/xulrunner-1.9/defaults/autoconfig/ instead.

Comment 9 RHEL Product and Program Management 2009-01-27 20:41:36 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 10 Jonathan Peatfield 2009-01-28 12:38:46 UTC
Actually this got fixed quite some time ago, for example try running:

  rpm -qlv firefox | grep -i autoconfig

on the current firefox-3.0.5-1.el5_2 version.  You should see /usr/lib/firefox-3.0.5/defaults/autoconfig showing as a symlink to /usr/lib/xulrunner-1.9/defaults/autoconfig (modulo %{_libdir} differences etc...)

Comment 11 Matěj Cepl 2009-01-28 13:55:03 UTC
Alan, could you still reproduce it with updated firefox?

Comment 15 Alan Matsuoka 2011-06-29 18:41:13 UTC
firefox has been rebased several times since this bug was filed and I haven't seen any recurrence of the problem. This bug should probably be closed.

Comment 16 Jonathan Peatfield 2011-06-29 21:37:39 UTC
See comment 10...  IMHO it got fixed years ago.  I suppose it might come back one day but...

Comment 18 Ludek Smid 2012-02-28 13:24:37 UTC
Closing based on comment #10 and comment #15.


Note You need to log in before you can comment on or make changes to this bug.