Bug 136080 - [patch] reinstate software update feature for themes and extensions
[patch] reinstate software update feature for themes and extensions
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
: Patch
: 141083 151792 164098 (view as bug list)
Depends On:
Blocks: FC4Update
  Show dependency treegraph
 
Reported: 2004-10-17 14:03 EDT by Matthew Miller
Modified: 2007-11-30 17:10 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-23 09:17:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
new patch leaves extension-update intact (2.00 KB, patch)
2004-11-29 14:13 EST, Matthew Miller
no flags Details | Diff
Enables software update for themes/extensions for Firefox 1.0.3 (3.32 KB, patch)
2005-05-03 11:04 EDT, Stephen Biggs
no flags Details | Diff
firefox-1.0.3-remove-software-update-but-leave-extensions.patch (1.79 KB, patch)
2005-05-04 08:33 EDT, Matthew Miller
no flags Details | Diff

  None (edit)
Description Matthew Miller 2004-10-17 14:03:28 EDT
Description of problem:

The latest version of Firefox in rawhide removes the software update
feature. This is correct for the application as a whole, but the
functionality shouldn't be disabled for extensions and themes
installed on a per-user basis. RPM/up2date/yum doesn't track those,
and so there's no other good update mechanism for them. The patch even
removes the "update" button from the extensions dialog.


Version-Release number of selected component (if applicable):

0.10.1-1.0PR1.12
Comment 1 Enrico Scholz 2004-11-22 10:44:59 EST
Please, can we disable the current disable-software-update patch for
now so that extensions can be upgraded again?

Being not able to upgrade potential insecure extensions is much more
worse than a non-working feature (firefox update).
Comment 2 Warren Togami 2004-11-29 04:24:36 EST
*** Bug 141083 has been marked as a duplicate of this bug. ***
Comment 3 Warren Togami 2004-11-29 04:27:10 EST
We are all in agreement that the update feature of extensions and
themes should be reinstated.  However caillon and blizzard have higher
priorities to deal with now.  The fastest way to solve this issue is
if someone submits a replacement patch that disables ONLY the firefox
update.
Comment 4 Christopher Aillon 2004-11-29 04:50:16 EST
There is no good way to do this currently within our limitations because of RPM.
 Ben Goodger is aware of this; I talked with him about it in person at the
Mozilla Foundation and it is planned work for Firefox 1.1.
Comment 5 Enrico Scholz 2004-11-29 04:51:20 EST
No, the fastest way (perhaps 30 seconds of work) would be to disable
the mentioned patch for now and wait for an upstream solution.
Comment 6 Christopher Aillon 2004-11-29 05:35:20 EST
Disabling the patch is quite silly when you consider that the reason this is an
issue at all is because people are downloading and installing random software
from the internet.  There is always going to be a game of cat and mouse when
dealing with that.  You aren't even guaranteed that you are going to get
extension updates for security issues.  It's up to the extension author.  If
they don't know, don't care, or don't have time, then you're still screwed.
Comment 7 Enrico Scholz 2004-11-29 08:17:53 EST
But currently, I am screwed everytime -- even when the extension author provides
security updates. I would have to open the extension dialog, visit the homepage
of the plugin, locate the download-link and install it manually. For 10-20
installed extensions, this will be a very time-consuming procedure. Nobody will
do this regularly which would be required for a secure system.

I agree, that the current firefox extension concept is an horror for
system-administrators (not working without X, extensions not signed, installed
extensions do not survive firefox updates, no removal procedure), but:

- the shipped firefox allows to install extensions; perhaps you should put
  | pref_locked("xpinstall.enabled", False)
  into a global configuration file. Ok, people will hate you and every FC 
  review will complain about the crippled firefox. But the system will be
  secure...

- upgrading firefox with the software-update method will probably not work 
  because of access restrictions. So the whole patch does not have any positive 
  effect overall.
Comment 8 Matthew Miller 2004-11-29 09:43:33 EST
Re comment #5: I don't think an upstream solution is going to be quick
in coming, since the upstream goals are likely to differ from ours.
("Don't use RPM -- we make a nice fancy installer!" [--fake quote])

I'll work on a reduced patch today if I get a chance.
Comment 9 Matthew Miller 2004-11-29 14:13:02 EST
Created attachment 107565 [details]
new patch leaves extension-update intact

Attached is a version of the software-update patch which leaves extension
updating intact. 

It leaves in the app.update.autoUpdateEnabled pref too, but makes it 'false' by
default. I'm not certain that's the right choice, but it seemed less intrusive.

Patch removes the GUI for turning that pref back on, but leaves the option to
toggle extension auto-update.

And, most importantly from my point of view, the "Update" button in the
extensions manager is back.

It's a pretty small patch:

$ diffstat firefox-1.0-software-update-leaveextensions.patch
 app/profile/firefox.js 			 |    4 ++--
 components/prefwindow/content/pref-advanced.xul |    4 ++++
 2 files changed, 6 insertions(+), 2 deletions(-)
Comment 10 Christopher Aillon 2004-11-29 14:21:12 EST
Upstream totally agrees with us here.  As I said, Ben has a fix in
mind.  Right now, their focus is on merging firefox back to cvs HEAD.
 When that is done, I expect a fix shortly.  If you want something
more immediate, then perhaps a better course of action would be to
flag down Ben on IRC and get him to share his thoughts as to what
should happen, and do that.  From what I understand, it shouldn't be
too much work.
Comment 11 Matthew Miller 2004-12-02 23:49:38 EST
I've checked on irc.mozilla.org a couple of times, and have been
unsuccessful at finding Ben to "flag down".

As per Warren's comment #3, I think my patch is the right thing to do
for  now. There may be some fancier extension management system in the
future, but utterly breaking the current one and hoping for a better
tomorrow doesn't seem like the right approach to me.

Instead, let's leave the completely-doesn't-work-with-Fedora/rpm
browser update system disabled, but not cripple the ability to update
user-installed and user-owned extensions.

Alternately, if you can summarize for me some different approach that
makes sense, I'll be happy to work on it.
Comment 12 Stig Hackvan 2004-12-03 12:42:17 EST
Matthew, your patch is good, BUT it should not remove the "Check Now"
button.  ALSO, it would be better to visibly disable the application
update checkbox with some explanatory text (leave the box and allow it
to be set, but have the text greyed out with a parenthetical
explaination "(this is an rpm distribution, use rpm to update
firefox)" of the disabling)...

Also, does your patch catch the case where people have the preference
set in their preferences already?  New profiles would default to
disabled app updates, but old profiles would still get application
update behaviour but lack a way to turn it off via the preferences dialog.

Finally, i do think it is fitting to discourage use of firefox's
application update, but I DON'T think its good to disable it entirely.
 I think it would be better to leave the feature operational but add a
few shrill confirmation dialogs recommending apt/yum/rpm for updates.

-- stig
Comment 13 Pavel Hlavnicka 2005-02-02 04:02:43 EST
+1 on comment 12
Comment 14 Matthew Miller 2005-02-02 05:20:45 EST
> Finally, i do think it is fitting to discourage use of firefox's
> application update, but I DON'T think its good to disable
> it entirely. I think it would be better to leave the feature 
> operational but add a few shrill confirmation dialogs recommending 
> apt/yum/rpm for updates.

Well, the problem is that it *isn't* operational -- if you leave the
feature there, it just plain doesn't work. (It might do something if
you're running as root, which you shouldn't be, but then it will just
mess up your system. If you're running as a normal user, it very
confusingly just fails.) Fixing it to actually work would be a major
undertaking.

> Also, does your patch catch the case where people have the 
> preference set in their preferences already?  New profiles would 

It changes the default; I believe that only settings changed from the
default are saved to the user's profile, so that should be okay in
most cases.
Comment 15 Enrico Scholz 2005-02-10 12:11:40 EST
Because Firefox 1.1 will not appear before June (which is *after* FC4), we can
not wait for an upstream solution as suggested by comment #4.
Comment 16 Matthew Miller 2005-02-10 12:21:22 EST
We've been using my patch here since December, and it works fine.
Comment 17 Matthew Miller 2005-02-28 16:19:51 EST
This patch still applies to the 1.0.1 update, by the way, and I still believe
that it is the right thing to do until some magical real solution is available.
Comment 18 Matthew Miller 2005-03-24 10:51:57 EST
This patch still applies to the 1.0.2 update, by the way, and I still believe
that it is the right thing to do until some magical real solution is available.
Comment 19 Warren Togami 2005-03-26 19:14:23 EST
*** Bug 151792 has been marked as a duplicate of this bug. ***
Comment 20 Matthew Miller 2005-04-20 14:33:41 EDT
Tested patch with the 1.0.3 update; still appears to apply cleanly and work fine.
Comment 21 Lars G 2005-04-21 00:38:19 EDT
inclusion of the latest patch to fc4's firefox would be great!
Comment 22 Stephen Biggs 2005-04-24 11:48:03 EDT
> Tested patch with the 1.0.3 update; still appears to apply cleanly
> and work fine.

I am running Firefox version 1.0.3-1.3.1 from Freshrpms updated by Synaptic/Apt.

Would you please explain exactly what you are talking about here?  The files
addressed in your patch (firefox.js and pref-advanced.xul) do not exist.
Comment 23 Stephen Biggs 2005-04-24 11:52:05 EDT
I'm not the only one with this problem...

See http://www.redhat.com/archives/rhl-list/2004-December/msg02716.html

As you can see, nobody answered this poster.  What is going on here??  I and the
poster and probably everybody else except you cannot apply your patch.
Comment 24 Matthew Miller 2005-04-24 12:38:12 EDT
Mr. or Ms. Akjlsdfhklajsr -- the patch applies to the source, not to the files
installed on your system by the binary (i386) RPM. This is normal and will be
the case for most patches you find in bugzilla (or anywhere).

If you'd like to learn about this, ask me on the Fedora list and I'll respond in
more detail -- it's really not an issue for this bug.
Comment 25 Stephen Biggs 2005-05-03 11:04:29 EDT
Created attachment 113966 [details]
Enables software update for themes/extensions for Firefox 1.0.3

Mr. Miller,

I am the poster with the funky email address.  I just not managed to get my
personal mail server up and running so I can now come out as myself correctly.

Your patch simply does NOT work with the current Fedora Firefox src rpm.  I got
mine as:
http://ayo.us5.freshrpms.net/fedora/linux/3/i386/RPMS.updates/firefox-1.0.3-1.3.1.i386.rpm


Your patch ignores the application of firefox-PR1-software-update.patch to this
source set.  Also, your patch removes the "Update Now" button from the
Preferences Advanced dialog which I wanted.

So, here is a patch that works for me (YMMV). This patch adds a patch file to
the SOURCES directory and modifies the SPEC file to apply it upon rpmbuild
invocation.

Instructions for patch are:
1. Download the attached patch to the home directory of the rpmbuilder, be it
root or wherever else; calling the downloaded file
'firefox-rpmsrc-swupdate.patch', or whatever else.  If the file is called
something else, that filename needs to be used below.
2. Install the above firefox source rpm in the rpm directory (rpm -ivh ...)
3. `cd' to the rpmbuild root directory (/usr/src/redhat or a non-root location
if building rpms as other than root)
4. Apply this patch to the firefox source installation as:
patch -p1 <~/firefox-rpmsrc-swupdate.patch
5. Build the rpms as usual (rpmbuild -ba --target=i386 SPEC/firefox.spec) and
install/update the binaries to now have a firefox running on Fedora Core 3 that
updates extensions and themes.
Comment 26 Matthew Miller 2005-05-03 11:12:45 EDT
Oh, I see your problem. The patch *replaces* the
firefox-PR1-software-update.patch -- it seemed unnecessary (and prone to errors
as the upstream code changes) to patch the software update code out and then
patch part of it back in.

If you leave the Update Now button in the prefs dialog, does it do the right
thing and *only* check for updated extensions and themes? What if the pref for
checking the app itself was enabled *before* the checkbox to change that pref
was hidden? That's why I left it out before.
Comment 27 Stephen Biggs 2005-05-03 11:28:20 EDT
How do I know for sure if it is only checking for extensions and themes?  I
*think* it is... I know that I was finally able to update a LOT of extensions
that had been stagnant for a long time in my Linux installation.  As for it
checking for the application update, also, I don't know...

Maybe just compile out completely the app update preference as the PR1 does
instead of messing around with it at all?
Comment 28 Matthew Miller 2005-05-03 23:50:35 EDT
After re-reading (and double-checking) my comment #14 above, I believe that it
would be no problem to reinstate the Check Now button in the advanced
preferences. I'll update the patch to leave that in. 
Comment 29 Stephen Biggs 2005-05-04 07:27:34 EDT
You need to address the problem of failure to be applied due to application of
the PR1 patch at normal installation and build of the source rpm. How exactly is
your patch to be applied?  Please provide complete usage instructions.

Are you saying that your patch is to be dropped into the SOURCES directory under
the name of "firefox-PR1-software-update.patch", replacing the original patch ?
 Because, if the SPEC file is not modified to apply another patch as my
"meta-patch" does, then that is what must be done for your patch to work at all.
 Sliding in a patch under the covers and naming it the same as an existing patch
is not acceptable.
Comment 30 Matthew Miller 2005-05-04 08:30:08 EDT
Stephen -- I'm not trying to provide an end-user solution here. It's not meant
to be an "after-the-fact" patch. Replacing the original patch is indeed the idea
-- *and the correct thing to do*.

Please don't clutter up this bug with more about it -- e-mail me directly or
post on the mailing list if you have further questions. But to head them off,
here's the here's the instructions:

1. Save the attached patch (will provide new version in a second) as 
   "firefox-1.0.3-remove-software-update-but-leave-extensions.patch"

2. Find the line in the firefox spec file that says:
   "Patch25:        firefox-PR1-software-update.patch"

3. Change that line to:
   "Patch25: firefox-1.0.3-remove-software-update-but-leave-extensions.patch"

4. Find the line later which says "%patch25 -p0" and change it to 
   "%patch25    -p1".

5. And there you are.

If it makes you happier to use a different number entirely, you could do that too.
Comment 31 Matthew Miller 2005-05-04 08:33:39 EDT
Created attachment 114007 [details]
firefox-1.0.3-remove-software-update-but-leave-extensions.patch

$ diffstat firefox-1.0.3-remove-software-update-but-leave-extensions.patch
 app/profile/firefox.js 			 |    4 ++--
 components/prefwindow/content/pref-advanced.xul |    3 ---
 2 files changed, 2 insertions(+), 5 deletions(-)

As you can see, this is a very small change -- much smaller than the current
firefox-PR1-software-update.patch. All it does is change the default for the
main software update prefs, and removes the one checkbox for turning it back
on.
Comment 32 Warren Togami 2005-10-01 00:33:42 EDT
*** Bug 164098 has been marked as a duplicate of this bug. ***
Comment 33 Edward Rudd 2005-12-15 11:31:15 EST
Is there any updates to this bug? ie.. does the firefox 1.5 builds in Fedora
Devel at least have extension updating enabled??
Comment 34 Kevin Fenzi 2005-12-16 15:10:22 EST
Yes, in firefox 1.5 in devel there is a 'Find Updates' button in the extensions
window and it appears to work. There is also a 'Find updates' button for themes. 
There are update prefs for 'firefox' 'installed extensions and themes' and
'search enegines'. 

The firefox update pref looks to have some issues. It was not selected by
default, I selected it and then it greyed out and I can't unselect it. 
Comment 35 Daniel Malmgren 2007-08-23 09:17:05 EDT
This has worked for ages now, right? Closing...

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