Firefox Rapid Release numbering
Milan
system is going to work out, I am still all for getting out more
stable releases as soon as possible. After many, many years of
Firefox, we are up to version 4. I honestly wouldn't like to see
Firefox 5, 6, 7, 8, and 9 be released in less time than it took to go
from Fx3 to Fx4.
My main concern is the numbering of the releases. Why was Firefox 5
chosen instead of Firefox 4.1? If there was some major overhaul then
it would be more understandable. But again, jumping from 4.0 to 4.1
doesn't mean hugely new features can't land; even if that were the
case, a jump to 4.2 or 4.5 would be fine.
tl;dr The rapid release system is cool, but the version numbering
should remain how it always has been.
smaug
Does the version numbering really matter?
I hope we'll eventually get to version-number-less
browsers. Web sites should detect each feature
they need separately and end user should
get automatic updates to the latest version of the browser.
For bug reporting and such browsers could just have some
build id (probably not available to web sites).
We haven't been consistent in numbering anyway.
Fx 1.5 and Fx 2.0 were pretty similar, at least
on platform level.
Update to Fx3.0 was a big one.
so was Fx3.5 (it was the first one to include JS JIT), and
Fx3.5 could have been Fx4.
Fx3.6 wasn't perhaps huge step from Fx3.5, but Fx3.6.4 was
a significant update (out-of-process plugins).
-Olli
Michael B.
I'm concerned about what happens years down the road when we reach
Firefx 35 or Firefox 135. It just won't sound right when marketing it.
Also, too many full-version change releases might make marketing harder
because people will be less enthusiastic and excited about each release.
Chrome can get away with it because Google has deep pockets to buy
advertising to compensate. Firefox doesn't have that.
Asa Dotzler
> On 04/23/2011 10:48 AM, Milan wrote:
>> tl;dr The rapid release system is cool, but the version numbering
>> should remain how it always has been.
>
> I'm concerned about what happens years down the road when we reach
> Firefx 35 or Firefox 135. It just won't sound right when marketing it.
Then you'll be pleased to know that Mozilla's Engagement team
(responsible for, among other things, marketing Firefox) aren't at all
worried. So, save yourself the fretting and instead look for something
productive to do :-)
- A
Ron Hunter
Huh? When was the last time you saw an ad on TV, or anywhere else, for
Google Chrome?
timeless
> Huh? When was the last time you saw an ad on TV, or anywhere else, for
> Google Chrome?
Google has run roadside billboard ads in at least England, and I've
only visited!
They also have had them in various airports.
As for tv ads,
http://googleblog.blogspot.com/2009/05/google-chrome-ads-on-tv.html
WLS
I saw some while watching TV shows on Hulu last year.
--
openSUSE 11.3(x86_64) - Gnome2.30 - SeaMonkey 2.1b3
Mil
5.0 instead of 4.2? I can't seem to find any reasoning while searching
this usegroup.
beltzner
The numbers are arbitrary and what they mean can (and is) changing. As Asa
said, the relevant teams involved seem happy with the decision, so unless
there are significant reasons not to (beyond taste and aesthetics) then I
think we should just move on.
cheers,
mike
On 24/04/2011 6:25 AM, "Mil" <milan....@gmail.com> wrote:
Robert Kaiser
> I'm concerned about what happens years down the road when we reach
> Firefx 35 or Firefox 135. It just won't sound right when marketing it.
Then you will be happy to hear that we will not market version numbers
any more. Those crazy numbers will only be there for internal tracking,
but that's as far as things go, users will never need them, they'll only
need "the newest Firefox release" (or Firefox beta or perhaps Aurora).
And anyone not running the newest one will not be supported anyhow, so
should upgrade to the newest one (but we'll do that silently for them
anyhow by default).
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Teoli
releases at merely bugfixes release.
We saw quite a few people having problems with Firefox 4 going back to
Firefox 3, or 3.0.19, thinking it is the last major release of Firefox,
instead of going back to a 3.6.x release.
With the new scheme, this problem disappears.
Not that this is much important as the marketing of the release number
will disappear very soon.
Adam Kowalczyk
Isn't this backwards? Changing status quo always has costs, if only
breaking habits, and it's usually up to the proponents to justify it. I
brought it up earlier and Christian agreed it is "a potential pain
point" so I would definitely expect there to be some concrete
advantages. Let me re-iterate what I said.
I can see some disadvantages as far as communication. Historically with
Firefox, as with most applications, users have learned to treat the
increase in version number as a shorthand indication of what kind of
changes to expect. The version number is the very first thing they look
at when deciding whether to upgrade (or whether to give Firefox another
try, in case of users of competing browsers). Is it is a maintenance
release or will it bring an upheaval to the way I work? I may not want
to deal with that just today.
From the comments on tech blogs and even on our Bugzilla, I can see
early adopters are also confused and not quite sure what to expect.
Sure, it's just a matter of time before they get used to it and start
treating Firefox versions like they do with Chrome - but again, there is
some cost in the temporary confusion and having to communicate what's
going on.
- Adam
Dave Townsend
number for a release when its cycle starts on mozilla-central, 18 weeks
before it releases and before we even know what will be in the release. We
can't easily adjust the version number by an amount relative to how much
work we think will be present in the release, far simpler to just increase
it by one for every release.
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
Robert Kaiser
> Is it is a maintenance
> release or will it bring an upheaval to the way I work?
Starting from Firefox 5, maintenance releases and releases that contain
new features are no difference any more. Firefox 6 is the maintenance
release to Firefox 5, while also bringing some new features. New
features will be way fewer than in any "major" release before, though,
as it's only work from 6 weeks that flow into such a release.
Also Firefox 5 will be unsupported the day Firefox 6 is out the door,
and updates will be silent and without asking the user, so (s)he doesn't
have to make that decision in the first place.
Asa Dotzler
> I can see some disadvantages as far as communication. Historically with
> Firefox, as with most applications, users have learned to treat the
> increase in version number as a shorthand indication of what kind of
> changes to expect.
This is not longer a concern. Users don't have to worry about versions.
There will only be one version available for new users and existing
users will all be on the latest Firefox version all of the time. There
is not significant value in knowing whether the version includes one fix
or one thousand fixes.
So far, every example you or anyone else opposed to this change have put
forward is something we've already considered. If you've got an example
that you think we haven't already considered, please offer it.
Do ask yourself before continuing this though, "is this something that
the people responsible for this change are likely to have overlooked?"
If so, then let's hear it. If not, please move on.
- A
Adam Kowalczyk
number upon merging mozilla-central to aurora, when the scope of the
release is mostly settled?
Dave Townsend
a1, a2, etc.) version for all cycles for a particular versions and it also
likely makes it easier to handle extension compatibility like this. There
are probably other reasons too.
Michael B.
> Adam Kowalczyk schrieb:
>> Is it is a maintenance
>> release or will it bring an upheaval to the way I work?
>
> Starting from Firefox 5, maintenance releases and releases that contain
> new features are no difference any more. Firefox 6 is the maintenance
> release to Firefox 5, while also bringing some new features. New
> features will be way fewer than in any "major" release before, though,
> as it's only work from 6 weeks that flow into such a release.
> Also Firefox 5 will be unsupported the day Firefox 6 is out the door,
> and updates will be silent and without asking the user, so (s)he doesn't
> have to make that decision in the first place.
>
> Robert Kaiser
>
>
Really? Not even maintenance releases for critical security
vulnerabilities? It wouldn't effect me because my linux distro would
backport fixes, but I can't imagine industry liking that much. End users
probably wouldn't notice though.
Boris Zbarsky
> Really? Not even maintenance releases for critical security
> vulnerabilities?
If we have to do a chemspill between the 6-week releases, we do a
chemspill. But once Firefox 6 ships, no more maintenance releases for
Firefox 5, yes.
> It wouldn't effect me because my linux distro would
> backport fixes, but I can't imagine industry liking that much. End users
> probably wouldn't notice though.
Indeed. The latter is more important to us, I think....
-Boris
JP Rosevear
Mozilla is doing some linux vendor outreach on this to raise awareness,
answer questions and see if there are items that can help ease this
transition without carrying too much burden on the mozilla project.
In my opinion, the biggest issue for the linux distros will be the
dependencies on xulrunner rather than Firefox itself. However the
number of deps has been reducing a lot over the last couple years in
favor of webkit embedding so it may mostly be an issue will older
enterprise distros that have long support cycles like SLE and RHEL.
-JP
--
JP Rosevear <j...@mozilla.com>
Mozilla
Robert Kaiser
> On 04/24/2011 11:47 AM, Robert Kaiser wrote:
>> Adam Kowalczyk schrieb:
>>> Is it is a maintenance
>>> release or will it bring an upheaval to the way I work?
>>
>> Starting from Firefox 5, maintenance releases and releases that contain
>> new features are no difference any more. Firefox 6 is the maintenance
>> release to Firefox 5, while also bringing some new features. New
>> features will be way fewer than in any "major" release before, though,
>> as it's only work from 6 weeks that flow into such a release.
>> Also Firefox 5 will be unsupported the day Firefox 6 is out the door,
>> and updates will be silent and without asking the user, so (s)he doesn't
>> have to make that decision in the first place.
>
> vulnerabilities?
For those that are right now in the date-based regular "maintenance"
updates, yes, those will just go into the next release, which replaces
those updates.
If you mean those with highly critical fixes for things that are already
out in public and where we fix only one single issue and push out
updates very fast, those are what we call "chemspill" updates, and those
will still happen as needed based on the current release and between the
regular 6-week maintenance+feature updates to the next version.
Still, even those only happen for the most-current version, which is
only "supported" for 6 weeks, until it's replaced by the next version.
Therefore only the "current release" counts at any point in time, and
version numbers grow irrelevant.
Ron Hunter
> On 4/24/2011 8:25 AM, Adam Kowalczyk wrote:
>
>> I can see some disadvantages as far as communication. Historically with
>> Firefox, as with most applications, users have learned to treat the
>> increase in version number as a shorthand indication of what kind of
>> changes to expect.
>
> This is not longer a concern. Users don't have to worry about versions.
> There will only be one version available for new users and existing
> users will all be on the latest Firefox version all of the time. There
> is not significant value in knowing whether the version includes one fix
> or one thousand fixes.
>
I find it hard to believe that all users will be on the same release,
even if you except beta testers from this, there will always be people
who simply refuse to upgrade to a new version. So, how do you figure
all users will be on the same version. It's a noble goal, but I can't
see how it can be achieved in a real world environment.
> So far, every example you or anyone else opposed to this change have put
> forward is something we've already considered. If you've got an example
> that you think we haven't already considered, please offer it.
>
> Do ask yourself before continuing this though, "is this something that
> the people responsible for this change are likely to have overlooked?"
> If so, then let's hear it. If not, please move on.
>
> - A
Sure. Most people just leave the automatic update feature turned on.
Others, such as myself, leave it on, but only for the notification. I
update when I want the update to run. Other people just don't update.
Have I missed something?
Ron Hunter
So, you really plan to push updates without user knowledge and consent?
If so, be ready for some legal issues.
beltzner
laws that would cause rise to any challenge when so doing. Also note that
the ability to turn off updates, however unwise and unrecommended, will
remain present.
cheers,
mike
Jean-Marc Desperrier
> you really plan to push updates without user knowledge and consent? If
> so, be ready for some legal issues.
That's what Google does with Chrome.
One important things they do also is to plug the update mechanism
everywhere (down to installing an upgrade plugin inside Firefox, but not
only that) so what when you run Chrome it's already updated, even if you
haven't used it in month.
I think it's an important part of their update strategy, which Mozilla
isn't quite ready to copy, and it will probably make a difference.
Asa Dotzler
> So, you really plan to push updates without user knowledge and consent?
> If so, be ready for some legal issues.
>
Ron, we already do unprompted updates and have been doing them for
basically the entire existence of Firefox.
If you think you have knowledge about the law that the Mozilla team
which developed this plan did not have, please cite it.
- A
Ron Hunter
Not here, since I disable their update task any time I see it.
I don't like software surprises, and I don't think I am alone in this.
Unless we can get just about 100% extension compatibility, this will
really annoy users, and create a support nightmare.
Ron Hunter
turned off those unprompted updates. I surely have. Texas has laws
that might apply, even though I haven't heard of a prosecution based on
software updating, it seems feasible. These days people will sue over
just about anything. Should an update cause a problem, the diagnosis
time would be extended just by not knowing that an update took place.
I am against making changes to a user's software without notification,
and explicit consent.
Asa Dotzler
I'm not particularly interested in what you personally do with your
software or what you are personally for or against here. You said "be
ready for some legal issues" and so I'll repeat: If you think you have
Daniel Holbert
>>> So, you really plan to push updates without user knowledge and consent?
>>> If so, be ready for some legal issues.
> Perhaps a good testpilot app. might be to see just how many users have
> turned off those unprompted updates. I surely have.
As has already been stated in related threads in the past few days: when
a user has set the pref to disable updates, we won't override that decision.
See e.g. LegNeato's message:
http://groups.google.com/group/mozilla.dev.planning/msg/44c17dd6e38bb8b7
(that post was w.r.t. a 3.0 --> 4.0 update, but I'm pretty sure it
applies here, too)
Christian Legnitto
On Apr 25, 2011, at 12:26 PM, Daniel Holbert wrote:
> On 04/25/2011 12:01 PM, Ron Hunter wrote:
>>>> So, you really plan to push updates without user knowledge and consent?
>>>> If so, be ready for some legal issues.
> [...]
>> Perhaps a good testpilot app. might be to see just how many users have
>> turned off those unprompted updates. I surely have.
I would bet < .001% of people do this. We may not have ironclad data but we are confident you are the outlier.
> As has already been stated in related threads in the past few days: when
> a user has set the pref to disable updates, we won't override that decision.
>
> See e.g. LegNeato's message:
> http://groups.google.com/group/mozilla.dev.planning/msg/44c17dd6e38bb8b7
> (that post was w.r.t. a 3.0 --> 4.0 update, but I'm pretty sure it
> applies here, too)
Correct.
This is what the preferences look like on Nightly:
If all the automatic checkboxes at the beginning are unchecked, we WILL NOT be forcing an update on users. This is what Ron (and other people too) seem to be worried about. This is a made up problem and we have no desire to force updates on those folks. Also, if we wanted people to never opt out of updates we'd just remove those options and sidestep the issue entirely.
If those ARE checked, regardless of the radio option we will send the FF5 update to the FF4 user. We will NOT be popping up the billboard telling people how awesome FF5 is and encouraging them to choose to update if they chose "automatically install". It'll be JUST like sending a 4.0.1 release, only the version in the binary is called 5.0. That's it.
Please everyone stop talking about suing. It is silly and detracts from possibly valid arguments. So unless you are a lawyer and see an actual problem based on real facts...stop.
Thanks,
Christian
Nicholas Nethercote
<dtow...@oxymoronical.com> wrote:
> It certainly makes things easier to understand if we use the same (albeit
> a1, a2, etc.) version for all cycles for a particular versions and it also
> likely makes it easier to handle extension compatibility like this. There
> are probably other reasons too.
It also avoids a giant bikeshed discussion every 6 weeks about what
the next version number should be.
Nick
Robert Kaiser
> I find it hard to believe that all users will be on the same release
All that matter will be. All others will not be support any more and
will be on their own. Those who refuse to be supported by us shouldn't
magically be supported.
> Sure. Most people just leave the automatic update feature turned on.
> Others, such as myself, leave it on, but only for the notification. I
> update when I want the update to run.
Then you will be unsupported between the moment you get the notification
and the moment you apply the update - which is no change to now, and as
soon as you keep that interval small, you also should be safe. And, of
course, have the amount of self-control you want to have, which I fully
understand (I usually prefer things that way myself - but then, we both
are far from the common users out there).
> Other people just don't update.
Those will just be unsupported, so we hope to keep that group as small
as possible, as the probability is not too small that their systems will
turn into botnet members after some time - unless those people are
really, really careful in what they do and know about every step they make.
Ron Hunter
> Ron Hunter schrieb:
>> I find it hard to believe that all users will be on the same release
>
> All that matter will be. All others will not be support any more and
> will be on their own. Those who refuse to be supported by us shouldn't
> magically be supported.
>
>> Sure. Most people just leave the automatic update feature turned on.
>> Others, such as myself, leave it on, but only for the notification. I
>> update when I want the update to run.
>
> Then you will be unsupported between the moment you get the notification
> and the moment you apply the update - which is no change to now, and as
> soon as you keep that interval small, you also should be safe. And, of
> course, have the amount of self-control you want to have, which I fully
> understand (I usually prefer things that way myself - but then, we both
> are far from the common users out there).
>
>> Other people just don't update.
>
> Those will just be unsupported, so we hope to keep that group as small
> as possible, as the probability is not too small that their systems will
> turn into botnet members after some time - unless those people are
> really, really careful in what they do and know about every step they make.
>
> Robert Kaiser
>
>
protect their computers. We can only hope they have firewalls (what's a
firewall?), and/or good operating practices (otherwise). I can't see
anything that can be done about them in a realistic scenario.
Boris Zbarsky
> Those who just don't update are likely to be the ones least able to
> protect their computers.
Since not updating will require going into the "Advanced" section in
preferences and changing some settings, do you really expect
non-technical users to be doing it much?
-Boris
Ron Hunter
a system that already has a profile. Maybe we need to make users create
a new profile before using the new rapid update system.
I have long felt that a lot of problems would be avoided if Firefox
installs made a new profile, and then asked the user what he wanted to
import from the old one.
Blair McBride
> Good point, Boris, for NEW users, but so many users will just install on
> a system that already has a profile. Maybe we need to make users create
> a new profile before using the new rapid update system.
> I have long felt that a lot of problems would be avoided if Firefox
> installs made a new profile, and then asked the user what he wanted to
> import from the old one.
Asa wrote up this recently, which aims to solve what you're describing:
https://wiki.mozilla.org/Firefox/Features/Factory_reset
- Blair
Ron Hunter
Very much like what I had in mind. Many long-time users have settings
that have remained in the .js files from several previous versions, and
countless extensions. The ability to clean this up would be a good last
resort trouble-shooting tool, while still retaining most of the user's
critical data.
Michael Verdi
https://wiki.mozilla.org/Features/Firefox
https://wiki.mozilla.org/Support/Firefox_Features/Clean_up_user_profile
and
https://wiki.mozilla.org/Support/Firefox_Features/Clean_install
Ideally, these would happen automatically on install/re-install without
any UI. It would make our two most difficult troubleshooting procedures
super simple and would literally help millions of Firefox users each year.
> ------------------------------------------------------------------------
>
> Ron Hunter <mailto:rphu...@charter.net>
> April 27, 2011 2:46 AM
>
>
>
>
> Very much like what I had in mind. Many long-time users have settings
> that have remained in the .js files from several previous versions,
> and countless extensions. The ability to clean this up would be a
> good last resort trouble-shooting tool, while still retaining most of
> the user's critical data.
>
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
> ------------------------------------------------------------------------
>
> Ron Hunter <mailto:rphu...@charter.net>
> April 26, 2011 1:29 PM
>
>
>
> Good point, Boris, for NEW users, but so many users will just install
> on a system that already has a profile. Maybe we need to make users
> create a new profile before using the new rapid update system.
> I have long felt that a lot of problems would be avoided if Firefox
> installs made a new profile, and then asked the user what he wanted to
> import from the old one.
>
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
> ------------------------------------------------------------------------
>
> Boris Zbarsky <mailto:bzba...@mit.edu>
> April 26, 2011 12:41 PM
>
>
>
>
> Since not updating will require going into the "Advanced" section in
> preferences and changing some settings, do you really expect
> non-technical users to be doing it much?
>
> -Boris
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
> ------------------------------------------------------------------------
>
> Ron Hunter <mailto:rphu...@charter.net>
> April 26, 2011 12:38 PM
>
>
>
> Those who just don't update are likely to be the ones least able to
> protect their computers. We can only hope they have firewalls (what's
> a firewall?), and/or good operating practices (otherwise). I can't
> see anything that can be done about them in a realistic scenario.
>
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
> ------------------------------------------------------------------------
>
> Robert Kaiser <mailto:ka...@kairo.at>
> April 26, 2011 10:33 AM
Benjamin Smedberg
> We actually have that feature (broken up into two smaller parts) as
> P1s https://wiki.mozilla.org/Features/Firefox
> https://wiki.mozilla.org/Support/Firefox_Features/Clean_up_user_profile
> and
> https://wiki.mozilla.org/Support/Firefox_Features/Clean_install
>
> Ideally, these would happen automatically on install/re-install
> without any UI. It would make our two most difficult troubleshooting
> procedures super simple and would literally help millions of Firefox
> users each year.
profile magically cleaned up for them when they install a new version,
unless they specifically ask for it somehow. I'd love this to be part of
the safe-mode dialog, but the technical details about what things to
clean up are formidable, assuming users want to keep anything at all:
from what I understand from previous discussions with support, users
want a clean slate 'except they want their bookmarks still', or
saved-passwords, or whatever happens to be important to that user.
--BDS
Robert Strong
Also, there are several ways that Firefox itself could do this across
all platforms. As long as you try to tie this into the installer itself
this won't be available for platforms other than Windows and on Windows
the account performing the installation can be a different account than
the one used with Firefox which makes it impossible for the installer to
work with the profile.
Robert
Ron Hunter
I would want my bookmarks, history, and passwords to be preserved. Part
of the reason for doing this kind of 'clean install' pretty much
precludes maintaining the add-ons, or screen customizations.
Cheng Wang
I think we're conflating two features here. Let me clarify:
1) Clean install. This SHOULD happen automatically and consist of
deleting old crap out of the install folder before reinstalling. No
profile folder involvement, no data loss. The proposed UI would be if
you're downloading the installer from mozilla.com it would clean up but
updates don't.
2) Clean profile (preserving bookmarks or what-have-you). This has to
be optional/user selected since there's significant dataloss. Right now,
the proposal is to have at least one access point for this feature be
the installer (where you select a repair mode or something) because a
broken profile can result in Firefox not starting (and not even starting
in safe mode) so we need a way to get in. We would also need to address
problems where someone completely breaks their menubar/browser chrome. I
understand that this wouldn't work for mac/linux so in those cases, we
may need to put a repair utility in the image/tarball or leave those
cases out. We can also have a secondary access point from the help menu
or the about menu or some other thing determined by UX.
There should never be wiping of profile information automatically in any
situation without being user initiated.
I'll be happy to meet with you in person if you want to talk through the
logistics/reasoning behind either of these.
> Robert
Robert Strong
that can be added that would affect the application. I have had
conversations with people that have stated that deleting the install
directory fixes problems but they haven't taken the time to identify the
file(s) that caused the problem. If there are things we should be
locking down that we aren't then we should definitely identify them and
lock them down so all platforms will benefit from it. I may be mistaken
but I believe the only problem area is the plugins directory at this time.
> 2) Clean profile (preserving bookmarks or what-have-you). This has to
> be optional/user selected since there's significant dataloss. Right
> now, the proposal is to have at least one access point for this
> feature be the installer (where you select a repair mode or something)
> because a broken profile can result in Firefox not starting (and not
> even starting in safe mode) so we need a way to get in. We would also
> need to address problems where someone completely breaks their
> menubar/browser chrome. I understand that this wouldn't work for
> mac/linux so in those cases, we may need to put a repair utility in
> the image/tarball or leave those cases out. We can also have a
> secondary access point from the help menu or the about menu or some
> other thing determined by UX.
1. there is no guarantee that the Windows installer is running as the
user that is trying to do the repair. We've had bugs where the user
expects the installer to be able to find their profile when the user has
manually launched the installer as a different user which is not possible.
2. teaching a non-Mozilla application how to manage Mozilla profile
files is to say the least a PITA and a lot of duplicate code.
3. the application can do this whether it be via the safe mode dialog or
some other method thereby removing 1 and 2 above.
4. If you really want this available from the Windows installer then a
command line option can be added to Firefox to initiate the process in
Firefox or a utility application. This wouldn't solve 1 but it wouldn't
make it any worse and this would be available on all platforms vs. just
Windows.
Robert
Robert Strong
> On 4/27/2011 10:11 AM, Cheng Wang wrote:
> that can be added that would affect the application. I have had
> conversations with people that have stated that deleting the install
> directory fixes problems but they haven't taken the time to identify
> the file(s) that caused the problem. If there are things we should be
> locking down that we aren't then we should definitely identify them
> and lock them down so all platforms will benefit from it. I may be
> mistaken but I believe the only problem area is the plugins directory
> at this time.
fix the problem which is where we should be focusing our limited resources.
Robert
timeless
Ime, that has 5+ copies of old Java Consoles which the Oracle updater
doesn't zap.
(Newer updaters for at least u25 will zap u24, but you can still have
u20..u23 or so...).
As this is application global, each user (including non admins) suffers.
Ron Hunter
You should get JavaRA from the Java site and run it. Only needs to run
once to get rid of all old versions.
timeless
offer it to them.
I didn't know about it (so thanks for the information), but
information is only useful if it's generally presented to those who
need / can benefit from it (in this case the Firefox user base with
old java console extensions)
Robert Strong
installing or updating to Firefox 4.
https://bugzilla.mozilla.org/show_bug.cgi?id=597235
If there are versions we are not removing could you file a bug with
their directory names?
btw: instead of deleting extensions from the app dir's extensions
directory if this is desired then extensions shouldn't be allowed to
install into that directory. This prevents problems vs. only fixing the
problem after the user performs actions and the user experience would be
awful in that they would have functionality one day and lost it the next
without any type of notification.
Thanks,
Robert
On 4/28/2011 7:07 AM, timeless wrote:
> If we know that a user should install or run something, we should
> offer it to them.
>
> I didn't know about it (so thanks for the information), but
> information is only useful if it's generally presented to those who
> need / can benefit from it (in this case the Firefox user base with
> old java console extensions)
>
> On 4/28/11, Ron Hunter<rphu...@charter.net> wrote:
timeless
> We did a pretty thorough job of removing the Java console extension when
> installing or updating to Firefox 4.
> https://bugzilla.mozilla.org/show_bug.cgi?id=597235
interesting. i wonder why this failed. the computer was running w7x64
w/ firefox 4 official.
> If there are versions we are not removing could you file a bug with their
> directory names?
hrm, kinda hard, we deleted them from the computers in question. i'm
pretty sure they were mostly between u19 and u24.
if i run across this, i'll file a bug.
> btw: instead of deleting extensions from the app dir's extensions directory
> if this is desired then extensions shouldn't be allowed to install into that
> directory.
I'd rather we move to a system where things the "appear" there are
offered as "available for installing" but aren't active until the user
says "please enable". the average user will not choose to do that,
which is the right thing tm. the only case where they will is if they
actively installed something and restarted firefox and *wanted* it.
timeless
> if i run across this, i'll file a bug.
for those wondering, i encountered another computer w/ this problem
and filed bug 654131