Linked by Thom Holwerda on Tue 27th Sep 2011 19:45 UTC, submitted by lemur2
Mozilla & Gecko clones Mozilla has released Firefox 7. Unlike releases of Firefox 5 and Firefox 6 which were relatively minor upgrades to the browser, Firefox 7 includes a number of significant improvements, most important of which is probably the drastically reduced memory usage.
Order by: Score:
Biggest change...
by UltraZelda64 on Tue 27th Sep 2011 19:51 UTC
UltraZelda64
Member since:
2006-12-05

...yet another f***ing inflated version number.

Reply Score: 6

RE: Biggest change...
by rklrkl on Tue 27th Sep 2011 20:24 UTC in reply to "Biggest change..."
rklrkl Member since:
2005-07-06

And Chrome inflating itself to version 14 (and updating itself far more often) is surely "twice as worse" than Firefox is? It is interesting to note how Mozilla is beginning to "hide" the version numbers of its products - the download buttons no longer reveal the version and if they could remove it from the "About..." box, I bet they would!

However, although they've been copying some of Chrome's features recently (and not all the copied Chrome ideas have been good ones, mind you), Mozilla has yet to copy the idea of "silent updating" that Chrome uses. This is why you see people whine incessantly about new Firefox releases (normally every 6-8 weeks unless there's an emergency fix) and no-one complains about the many more updates Chrome gets (every 2 weeks typically).

Also don't forget that IE on Windows often gets a monthly update as part of the "Patch Tuesday" - again, more often than Firefox, but no-one complains about that either (mainly because MS don't bother changing the major version number and it's "bundled" with a bunch other updates, which are often all automatically applied).

So, yes, Firefox increases its major version number at about the same rate as Chrome, but like Chrome, just learn to ignore the version number really. I think Mozilla should have done a year.release version scheme (e.g. 2011.01 for the first release of the year and so on - gives them 99 releases [which could include alphas and betas inbetween stable releases] a year, which should be more than enough). That way, no-one would moan about the major version changing because that would only happen at least 12 months apart!

Reply Score: 11

RE[2]: Biggest change...
by Thom_Holwerda on Tue 27th Sep 2011 20:32 UTC in reply to "RE: Biggest change..."
Thom_Holwerda Member since:
2005-06-29

So, yes, Firefox increases its major version number at about the same rate as Chrome, but like Chrome, just learn to ignore the version number really.


Bingo.

Version numbers are retarded anyway when it comes to browsers.

Reply Score: 2

RE[3]: Biggest change...
by ephracis on Tue 27th Sep 2011 20:56 UTC in reply to "RE[2]: Biggest change..."
ephracis Member since:
2007-09-23

Version numbers are retarded when it comes to consumer software that doesn't have any platform characteristics.

Browser have extensions, but maybe the solution is to either promise backward compatibility or use a distinct version number for the "extension platform" visible only to developers and power users.

Anyway, I still see the need for version numbers when it comes to libc and linux images.

Reply Score: 8

RE[2]: Biggest change...
by shmerl on Tue 27th Sep 2011 20:41 UTC in reply to "RE: Biggest change..."
shmerl Member since:
2010-06-08

and if they could remove it from the "About..." box, I bet they would!

They plan to. But the version of course will not be gone completely. It still will be shown in about:support (Help > Troubleshooting Information in the menu).

Edited 2011-09-27 20:41 UTC

Reply Score: 2

RE[2]: Biggest change...
by ephracis on Tue 27th Sep 2011 20:54 UTC in reply to "RE: Biggest change..."
ephracis Member since:
2007-09-23

I think Mozilla should have done a year.release version scheme (e.g. 2011.01 for the first release of the year and so on - gives them 99 releases [which could include alphas and betas inbetween stable releases] a year, which should be more than enough). That way, no-one would moan about the major version changing because that would only happen at least 12 months apart!

But that means that they would go from 7 to 2011. Inflation of almost 3000%!

Reply Score: 9

RE[2]: Biggest change...
by Luminair on Tue 27th Sep 2011 21:04 UTC in reply to "RE: Biggest change..."
Luminair Member since:
2007-03-30

So, yes, Firefox increases its major version number at about the same rate as Chrome, but like Chrome, just learn to ignore the version number really.


Thanks for the advice.

Reply Score: 2

RE: Biggest change...
by shmerl on Tue 27th Sep 2011 20:35 UTC in reply to "Biggest change..."
shmerl Member since:
2010-06-08

Who cares. Memory reduction is very useful. Thanks Mozilla.

Reply Score: 6

RE[2]: Biggest change...
by allanregistos on Wed 28th Sep 2011 06:53 UTC in reply to "RE: Biggest change..."
allanregistos Member since:
2011-02-10

Who cares. Memory reduction is very useful. Thanks Mozilla.

I have here an 8Gb, Win7 64, quad Phenom box and have it installed Firefox 7.0. As a Google Chrome user, I tested firefox right away, doing my usual browsing habits opening tabs, typing a search query, then it suddenly very slow, I can't even click the tabs and I have to wait for 10 to 15 secs. I have never experience this in Google Chrome, unless there are too many tabs I may experience slowness.

Forget about the memory reduction, it ain't useful when it will compromise stability. Stability is more important to users. Now I'm back again at Google Chrome. When time is wasted, it is turn off.

Reply Score: 5

RE[3]: Biggest change...
by WereCatf on Wed 28th Sep 2011 07:06 UTC in reply to "RE[2]: Biggest change..."
WereCatf Member since:
2006-02-15

doing my usual browsing habits opening tabs, typing a search query, then it suddenly very slow, I can't even click the tabs and I have to wait for 10 to 15 secs.


I have no idea what causes it, but I get similar experience: whenever I fire up Firefox for the first time it's useable for a few seconds, then completely locks up for about 30 seconds during which it won't respond to anything. After those 30 seconds though it doesn't do that again.

It's a nuisance, but since I only fire up the browser like once a day it's not that big deal for me. I can imagine it being more of that for people who needs to restart browser/PC often, though.

Reply Score: 2

RE[4]: Biggest change...
by lemur2 on Wed 28th Sep 2011 07:25 UTC in reply to "RE[3]: Biggest change..."
lemur2 Member since:
2007-02-17

"doing my usual browsing habits opening tabs, typing a search query, then it suddenly very slow, I can't even click the tabs and I have to wait for 10 to 15 secs.
I have no idea what causes it, but I get similar experience: whenever I fire up Firefox for the first time it's useable for a few seconds, then completely locks up for about 30 seconds during which it won't respond to anything. After those 30 seconds though it doesn't do that again. It's a nuisance, but since I only fire up the browser like once a day it's not that big deal for me. I can imagine it being more of that for people who needs to restart browser/PC often, though. "

Try increasing the parameter browser.sessionstore.interval under about:config.

http://www.techmynd.com/firefox-freezes-for-a-moment-after-every-10...

On some systems the default value for this parameter (10 seconds) causes some problems. The value is stored in milliseconds, so perhaps try a value of 60000 (60 seconds). This might solve the issue for you.

Edited 2011-09-28 07:26 UTC

Reply Score: 2

RE[5]: Biggest change...
by WereCatf on Wed 28th Sep 2011 07:28 UTC in reply to "RE[4]: Biggest change..."
WereCatf Member since:
2006-02-15

Try increasing the parameter browser.sessionstore.interval under about:config.

http://www.techmynd.com/firefox-freezes-for-a-moment-after-every-10...

On some systems the default value for this parameter (10 seconds) causes some problems. The value is stored in milliseconds, so perhaps try a value of 60000 (60 seconds). This might solve the issue for you.


You didn't read completely what I said: it doesn't freeze up periodically, it freezes up only when I first launch it and stays frozen for up to 30 seconds, after which it works fine until I restart it.

Reply Score: 2

RE[6]: Biggest change...
by Alfman on Wed 28th Sep 2011 08:39 UTC in reply to "RE[5]: Biggest change..."
Alfman Member since:
2011-01-28

WereCatf,

This happens every time you start FF (and not just once per day/session)?

Is there any disk/network/cpu activity happening in the meantime?


If CPU activity is normal, then it implies firefox is waiting for IO for some reason, you could try "strace firefox" to see exactly what it's trying to do. While it's hung, check if moving the mouse causes spurious events. If yes, then FF is receiving input but is not acting on it.

Given your problem, you will see FF blocked on one single call for >20s, or you will see it looping over a sequence of calls for >20s.

For me, while it's running normally, I see this over and over again.

gettimeofday({1317197393, 220526}, NULL) = 0
read(4, 0xb7384058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1317197393, 220613}, NULL) = 0
poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=19, events=POLLIN}, {fd=20, events=POLLIN}], 5, 0) = 0 (Timeout)

The "read(4...)" is FF checking the X-server for input. It returns EAGAIN because this is a non-blocking socket with no input.

The "poll(...)" is FF checking if any of it's descriptors have input (I have no idea what these descriptors are, other than 4).

Dev Commentary: The read call is totally redundant with the poll call and should only be triggered by the poll. Furthermore I'm not keen on how FF is constantly timing out while it's not doing anything useful, ideally it would schedule a background timer instead of maintaining it's own clock as it appears to be doing with "gettimeofday".


It occurred to me you may not be using linux...oh well.

Reply Score: 3

RE[6]: Biggest change...
by lemur2 on Wed 28th Sep 2011 09:13 UTC in reply to "RE[5]: Biggest change..."
lemur2 Member since:
2007-02-17

"Try increasing the parameter browser.sessionstore.interval under about:config.

http://www.techmynd.com/firefox-freezes-for-a-moment-after-every-10...

On some systems the default value for this parameter (10 seconds) causes some problems. The value is stored in milliseconds, so perhaps try a value of 60000 (60 seconds). This might solve the issue for you.


You didn't read completely what I said: it doesn't freeze up periodically, it freezes up only when I first launch it and stays frozen for up to 30 seconds, after which it works fine until I restart it.
"

Did you try it?

As the name browser.sessionstore.interval implies, this parameter is the interval at which Firefox tries to save the current session, for the purposes of a possible future session restore.

Session restore itself only occurs when you start the browser. If, on starting (on your machine) Firefox is not fast enough to restore the 'as saved' session in the period of the browser.sessionstore.interval, then Firefox (only on startup) will be trying to save and restore a session at the same time. Only on startup.

Edited 2011-09-28 09:17 UTC

Reply Score: 2

RE[7]: Biggest change...
by lemur2 on Wed 28th Sep 2011 10:32 UTC in reply to "RE[6]: Biggest change..."
lemur2 Member since:
2007-02-17

Did you try it?

As the name browser.sessionstore.interval implies, this parameter is the interval at which Firefox tries to save the current session, for the purposes of a possible future session restore.

Session restore itself only occurs when you start the browser. If, on starting (on your machine) Firefox is not fast enough to restore the 'as saved' session in the period of the browser.sessionstore.interval, then Firefox (only on startup) will be trying to save and restore a session at the same time. Only on startup.


PS: Another thing which you can easily do to reduce the startup time on slow systems, and thereby avoid similar freezes, is to clear the browser cache and then drastically reduce its size. On my under-powered netbook, I cleared the browser cache and reduced it from the default of 1024 MB to just 100 MB. This resulted in great improvement in startup.

Edited 2011-09-28 10:35 UTC

Reply Score: 2

RE[7]: Biggest change...
by WereCatf on Wed 28th Sep 2011 10:44 UTC in reply to "RE[6]: Biggest change..."
WereCatf Member since:
2006-02-15

As the name browser.sessionstore.interval implies, this parameter is the interval at which Firefox tries to save the current session, for the purposes of a possible future session restore.


I changed the value to 30 seconds and it seems to be working.

will be trying to save and restore a session at the same time.


That is some serious brainfart, even a moderately experienced coder should be totally ashamed of himself. It's not hard to enable session saving AFTER a session has been restored..

Reply Score: 3

RE: Biggest change...
by Soulbender on Tue 27th Sep 2011 20:56 UTC in reply to "Biggest change..."
Soulbender Member since:
2005-08-18

Who cares? It's just the version number, a completely arbitrary indicator of that "here's a new version,some things have changed".

Edited 2011-09-27 20:57 UTC

Reply Score: 6

RE[2]: Biggest change...
by UltraZelda64 on Tue 27th Sep 2011 22:47 UTC in reply to "RE: Biggest change..."
UltraZelda64 Member since:
2006-12-05

No, there was a time you could look at the version number and tell if there were some major changes or not. You know, things like major compatibility and UI changes. Firefox's version number has only recently become "completely arbitrary"... since, what, Firefox 4, 5? Never mind the whole incompatible extensions mess that is brought to extreme levels with these rapid version number inflations.

Edited 2011-09-27 22:48 UTC

Reply Score: 2

RE[3]: Biggest change...
by Fergy on Wed 28th Sep 2011 09:40 UTC in reply to "RE[2]: Biggest change..."
Fergy Member since:
2006-04-10

No, there was a time you could look at the version number and tell if there were some major changes or not. You know, things like major compatibility and UI changes. Firefox's version number has only recently become "completely arbitrary"... since, what, Firefox 4, 5? Never mind the whole incompatible extensions mess that is brought to extreme levels with these rapid version number inflations.

V1.5 was more like a V1.1 - V3 was more like a V4 in comparison with V2 - V3.5 was meant to be V3.1 but became too big - V3.6 was more like a service pack to V3.5 so maybe make V3.5 a V4 and V3.6 a V4.1 - V5 should be V4.1 and V6 should be V4.2 but V7 should be V5.
Should we really use version numbers as an indication of how many changes were made? Do you think 3.6 broke less extensions than 5?

Reply Score: 2

RE[3]: Biggest change...
by lemur2 on Wed 28th Sep 2011 09:46 UTC in reply to "RE[2]: Biggest change..."
lemur2 Member since:
2007-02-17

No, there was a time you could look at the version number and tell if there were some major changes or not. You know, things like major compatibility and UI changes. Firefox's version number has only recently become "completely arbitrary"... since, what, Firefox 4, 5? Never mind the whole incompatible extensions mess that is brought to extreme levels with these rapid version number inflations.


Firefox version number has nothing to do with compatibility changes.

Mozilla has been desperately asking authors of extensions to avoid inspecting the version number to try to infer anything about compatibility.

Reply Score: 3

RE[4]: Biggest change...
by vodoomoth on Wed 28th Sep 2011 11:24 UTC in reply to "RE[3]: Biggest change..."
vodoomoth Member since:
2010-03-30


Firefox version number has nothing to do with compatibility changes.

In practice, it does for users: extensions stop working or worse, they are deactivated by FF without the warning we were given with FF 4. I've seen this with the Java Console, the .NET thingy and other plugins. Now, because we have no obvious way to get rid of those system-wide extensions, they sit there in the extensions list.

Extensions that stop working are the most annoying thing about FF.

Mozilla should have come up with a better way for extensions developers to do what they think they're doing by testing version numbers. Yeah, I know it's very easy to say in retrospect. If the stubborn devs keep doing what they are now told not do do, it's because they've been given the means to do it in the first place.

Reply Score: 3

RE[5]: Biggest change...
by lemur2 on Wed 28th Sep 2011 11:37 UTC in reply to "RE[4]: Biggest change..."
lemur2 Member since:
2007-02-17

"
Firefox version number has nothing to do with compatibility changes.

In practice, it does for users: extensions stop working or worse, they are deactivated by FF without the warning we were given with FF 4. I've seen this with the Java Console, the .NET thingy and other plugins. Now, because we have no obvious way to get rid of those system-wide extensions, they sit there in the extensions list.
"

Run Firefox as an administrator.

http://www.pcworld.com/article/213114/remove_old_versions_of_the_ja...

Extensions that stop working are the most annoying thing about FF.

Mozilla should have come up with a better way for extensions developers to do what they think they're doing by testing version numbers. Yeah, I know it's very easy to say in retrospect. If the stubborn devs keep doing what they are now told not do do, it's because they've been given the means to do it in the first place.


https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-...

About this Add-on

After installing the Add-on Compatibility Reporter, your incompatible extensions will become enabled for you to test whether they still work with the version of Firefox or Thunderbird that you're using. If you notice that one of your add-ons doesn't seem to be working the same way it did in previous versions of the application, just open the Add-ons Manager and click Compatibility next to that add-on to send a report to Mozilla.

Even if your add-ons all work fine, if they're marked incompatible, please let us know that they work fine by submitting a success report so we can encourage the add-on developer to update their compatibility information.

We'll collect all of the reports and let add-on developers know what users are having problems with, or if their add-ons seem to work just fine in future versions of the product.


https://addons.mozilla.org/en-US/firefox/compatibility/reporter

Reports submitted to us through the Add-on Compatibility Reporter are collected here for developers to view. These reports help us determine which add-ons will need help supporting an upcoming Firefox version.


Edited 2011-09-28 11:40 UTC

Reply Score: 2

RE[6]: Biggest change...
by vodoomoth on Wed 28th Sep 2011 13:27 UTC in reply to "RE[5]: Biggest change..."
vodoomoth Member since:
2010-03-30

Many thanks.

Reply Score: 2

RE[5]: Biggest change...
by Soulbender on Wed 28th Sep 2011 18:28 UTC in reply to "RE[4]: Biggest change..."
Soulbender Member since:
2005-08-18

If the stubborn devs keep doing what they are now told not do do, it's because they've been given the means to do it in the first place.


No, it's because they're either too lazy or not good enough.

Reply Score: 2

RE[3]: Biggest change...
by Soulbender on Wed 28th Sep 2011 18:26 UTC in reply to "RE[2]: Biggest change..."
Soulbender Member since:
2005-08-18

No, there was a time you could look at the version number and tell if there were some major changes or not. You know, things like major compatibility and UI changes.


That's what release notes are for. It's not like the version number will tell you exactly what changes there are and what problems you can expect.

Never mind the whole incompatible extensions mess that is brought to extreme levels with these rapid version number inflations.


I guess the extension authors have to write better code then.

Reply Score: 2

RE[4]: Biggest change...
by UltraZelda64 on Fri 30th Sep 2011 03:44 UTC in reply to "RE[3]: Biggest change..."
UltraZelda64 Member since:
2006-12-05

That's what release notes are for. It's not like the version number will tell you exactly what changes there are and what problems you can expect.

Yes, but it's nice when the version number gives you a little hint as to what to expect.

Reply Score: 2

RE: Biggest change...
by pjafrombbay on Wed 28th Sep 2011 04:32 UTC in reply to "Biggest change..."
pjafrombbay Member since:
2005-07-31

UZ64 said: ...yet another f***ing inflated version number.

Well thanks for yet another really useful and insightful comment. You must put a great deal of time and effort into your analysis.

Regards,
Machiavelli

Reply Score: 2

Still have some work to do
by FunkyELF on Tue 27th Sep 2011 20:52 UTC
FunkyELF
Member since:
2006-07-26

I logged out of Google.com in Firefox and Chrome.
Closed all windows and unpinned all tabs, went to google.com and closed the browsers.

Fired them back up and Chrome is using 48M while Firefox is using 85M.

The real benchmark is what the memory footprint will look like after real use and leaving it up for a while.

Reply Score: 3

Stop breaking plugins
by tux68 on Tue 27th Sep 2011 20:53 UTC
tux68
Member since:
2006-10-24

It's the features added by extensions that keep me faithful to Firefox. I don't have the solution, but it's a real problem. With every upgrade one or more addons that I use is disabled and makes the new improved version of Firefox feel like a step backward.

Edited 2011-09-27 20:55 UTC

Reply Score: 11

RE: Stop breaking plugins
by lemur2 on Tue 27th Sep 2011 22:57 UTC in reply to "Stop breaking plugins"
lemur2 Member since:
2007-02-17

It's the features added by extensions that keep me faithful to Firefox. I don't have the solution, but it's a real problem. With every upgrade one or more addons that I use is disabled and makes the new improved version of Firefox feel like a step backward.


I've never had any problem, except for the Australian dictionary. I simply used the GB dictionary instead. In addition for one update, one of my addons wasn't available for a week or so.

The significant majority of the addons hosted on addons.mozilla.org should work after an update, since Mozilla automatically verifies them for compatibility.

Just let them update.

Reply Score: 1

RE[2]: Stop breaking plugins
by sorpigal on Thu 29th Sep 2011 18:28 UTC in reply to "RE: Stop breaking plugins"
sorpigal Member since:
2005-11-02

It's nice that it Works For You, but that's no answer to the problem of what to do when it doesn't work.

My experience is like the grandparent: Every FF update breaks at least one extension that I use daily. It's a good thing that I can control when I update so that I can delay upgrading until all my extensions have been updated. Oh, wait! Apparently FF updates never break anything, so Mozilla is going to make it all transparent, automatic and impossible to opt out of. Well that's good news; it's not as if I ever have to worry about testing my web sites on older versions of the engine... oh, wait.

You get the idea.

Reply Score: 2

RE[3]: Stop breaking plugins
by lemur2 on Thu 29th Sep 2011 23:09 UTC in reply to "RE[2]: Stop breaking plugins"
lemur2 Member since:
2007-02-17

It's nice that it Works For You, but that's no answer to the problem of what to do when it doesn't work. My experience is like the grandparent: Every FF update breaks at least one extension that I use daily. It's a good thing that I can control when I update so that I can delay upgrading until all my extensions have been updated. Oh, wait! Apparently FF updates never break anything, so Mozilla is going to make it all transparent, automatic and impossible to opt out of. Well that's good news; it's not as if I ever have to worry about testing my web sites on older versions of the engine... oh, wait. You get the idea.


Addons are actually compatible 99% of the time. Addons hosted at Mozilla's site, addons.mozilla.org, are automatically tested and updated by Mozilla. One would be quite unlucky to have one of the 1% of addons (from addons.mozilla.org) that was not automatically compatible after an update.

So the "problem" is this ... the majority of addons, especially with Windows users, don't actually come from addons.mozilla.org. Up to 75% of addons in use are outside of Mozilla's direct influence, Mozilla can't do anything about them. Currently Firefox takes the approach of extreme caution and disables these "external to Mozilla" addons, it doesn't just assume they will still work with a new version of the browser unless the addons specifically indicate that they will. People have to update these "external to Mozilla" addons seperately.

Instead of doing that, people just jump on Internet forums and complain that "Firefox update broke my addon". Sigh!

OK, so what to do about it. There are basically three options:

1. First and foremost, go the source (external to addons.mozilla.org) of the addon which has been disabled after a Firefox update, and see if there is a corresponding update for the addon. If there is, download it and install it (by opening the .xpi file in Firefox). Sweet.

2. If the source of the addon hasn't updated it, it is still quite likely that the old version of the addon will still work, and that Firefox has been overly cautious in marking it as disabled. To override this, install an addon from addons.mozilla.org called the "Addon Compatibility Reporter". Within this addon is the ability to enable older addons that Firefox has disabled after an update. So use the Addon Compatibility Reporter to mark the old disabled addon as enabled once again, and try it. In the vast majority of cases (perhaps up to 99% of cases), the old addon will still work with the new Firefox version.

3. If the old addon doesn't work, and the original source of the old addon won't be updating it, then have a look around. There are literally many thousands of addons available for Firefox. It is quite likely that with a bit of effort you can find a suitable replacement.

Hope this helps.

Edited 2011-09-29 23:12 UTC

Reply Score: 2

RE[4]: Stop breaking plugins
by sorpigal on Fri 30th Sep 2011 11:18 UTC in reply to "RE[3]: Stop breaking plugins"
sorpigal Member since:
2005-11-02

So the "problem" is this ... the majority of addons, especially with Windows users, don't actually come from addons.mozilla.org. Up to 75% of addons in use are outside of Mozilla's direct influence, Mozilla can't do anything about them.

Mozilla can do a lot about them, it doesn't have to control them to not break them.

Currently Firefox takes the approach of extreme caution and disables these "external to Mozilla" addons, it doesn't just assume they will still work with a new version of the browser unless the addons specifically indicate that they will.

Which is a problem with, and a bug in, Firefox.

People have to update these "external to Mozilla" addons seperately.

No kidding. Of course, the third party addons are not necessarily updated as soon as the new release of Firefox is out... which means that people who use them definitely don't want automatic updates. But, it's OK! 99% of a subset of 25% of addons won't break, so automatic updates are OK.

Instead of doing that, people just jump on Internet forums and complain that "Firefox update broke my addon". Sigh!

In fact, Firefox did break my addon. The facts are these:

1) Firefox refuses to run addons which don't specifically advertise themselves as compatible by explicit version range.
2) Mozilla does not provide a mechanism for addon developers to specify or check for features on which they rely.
3) Mozilla does not provide any guarantees of API stability between major versions.
4) All versions are now major versions

Why is there no message like this after an upgrade?

An extension called FROBRICTATE does not have a new version known to work with FIREFOX 9001. Would you like to disable the extension (recommended) or continue to use it? Using it anyway may cause Firefox to crash!

[Disable it] [Use it anyway]


Firefox doens't do this; that's Firefox's fault, not the extension author's.

Why doesn't Firefox provide a "or newer" version-check option? "My extension works with 4.0 or newer" - meaning newer Firefox versions assume it's compatible. Yes, in theory it could break on some unknown future version... which is why it would be nice if you could somehow limit how long "or newer" is assumed to be compatible (like, say, by claiming "4.x through 5.x" and then having Mozilla only bump the major version number once a year) but apparently that's just not cool enough. An extension could break in the very next release, even though to claims "or newer"--it's impossible to know for sure, but the consequences of this are far less horrendous than "break"ing it *for sure* by disabling it.

Firefox could provide a simple mechanism to force-enable extensions which were disabled due to failing the version compatibility check. No such mechanism is provided by default (ridiculous, convoluted steps are required to make this work). A crash handler which knows about force-enabled extensions and knows to re-disable those first when a crash occurs would also be nice.

First and foremost, go the source (external to addons.mozilla.org) of the addon which has been disabled after a Firefox update, and see if there is a corresponding update for the addon. If there is, download it and install it

Stop treating users like children. Most third party addons that I use provide a repository, just like Mozilla does. I already check those which don't. The problem isn't "The user is too dumb to check for updates and blames Firefox for it." The problem is "The addon doesn't have a newer version" and the user can't opt-out of upgrades and the user doesn't necessarily know how to extract an XPI and bump the claimed compatibility number himself and the user doesn't have any reasonable GUI way to do this.

If the source of the addon hasn't updated it, it is still quite likely that the old version of the addon will still work, and that Firefox has been overly cautious in marking it as disabled.

A thing for which I blame Firefox (and Mozilla), hence "Firefox broke my addon."

To override this, install an addon from addons.mozilla.org called the "Addon Compatibility Reporter". Within this addon is the ability to enable older addons that Firefox has disabled after an update.

What earthly reason is there for not providing this addon by default, or (since it's overkill for most users) some subset of its features? See my various rants above.

In the vast majority of cases (perhaps up to 99% of cases), the old addon will still work with the new Firefox version.

If this is the case why was the decision ever made to default to assuming that it won't work? Why wasn't that decision reversed at least at the time of the release of Firefox 4.0? It could have been changed, it wasn't, and I blame Mozilla.

If the old addon doesn't work, and the original source of the old addon won't be updating it, then have a look around. There are literally many thousands of addons available for Firefox. It is quite likely that with a bit of effort you can find a suitable replacement.

There are thousands covering common uses but very few covering niches. Actual cases where the addons aren't compatible and aren't being updated are so rare that I don't personally care, but it's a case that justifies not auto-updating Firefox for some users.

Hope this helps.

Telling me things I already know and trotting out tired excuses are not things that are likely to be of any help (and weren't).

Reply Score: 2

RE[5]: Stop breaking plugins
by Alfman on Fri 30th Sep 2011 13:01 UTC in reply to "RE[4]: Stop breaking plugins"
Alfman Member since:
2011-01-28

sorpigal,

I totally feel your frustration. Ever since FF3, this has been an ongoing issue - I lost the use of several of my favorite developer addons. Of course at that time, there may have been a genuine incompatibility, rather than an incompatibility caused by mismatched version numbers.

Some might blame the authors for failing to update version numbers in app metadata for each new FF release, but like you, I feel this was a fundamental software engineering problem which FF introduced itself.

Just imagine if other architectures choose to use version numbers for forward compatibility testing instead of checking for compatible interfaces: Java apps which run only on specific JVM versions. Windows apps which can't run on newer windows. Linux binaries which break every new kernel release.

Hopefully FF10 will finally fix this, but it shouldn't have taken so long.

"What earthly reason is there for not providing this addon by default, or (since it's overkill for most users) some subset of its features? See my various rants above."

As far as I can tell, "Addon Compatibility Reporter" does not enable disabled addons, it merely enables you to report information back to mozilla. However, I discovered that "Nightly Tester Tools" does enable a forced compatibility override. It you try it, let us know if it works on versions prior to FF10.

Reply Score: 2

RE: Stop breaking plugins
by Sauron on Wed 28th Sep 2011 02:21 UTC in reply to "Stop breaking plugins"
Sauron Member since:
2005-08-02

Got fed up with Firefox because of this, and recently switched browsers to Lunascape. It's switchable on the fly between 3 engines, "Firefox's Gecko, Chrome's Webkit, and IE's Trident engine". It also uses Firefox extensions with no problems, and no breaking compatibility every week. Also very configurable.

Reply Score: 1

RE[2]: Stop breaking plugins
by cmost on Wed 28th Sep 2011 11:28 UTC in reply to "RE: Stop breaking plugins"
cmost Member since:
2006-07-16

Got fed up with Firefox because of this, and recently switched browsers to Lunascape. It's switchable on the fly between 3 engines, "Firefox's Gecko, Chrome's Webkit, and IE's Trident engine". It also uses Firefox extensions with no problems, and no breaking compatibility every week. Also very configurable.


Too bad there isn't a Linux version...

Reply Score: 2

RE[3]: Stop breaking plugins
by Sauron on Wed 28th Sep 2011 15:26 UTC in reply to "RE[2]: Stop breaking plugins"
Sauron Member since:
2005-08-02

Yeah, I'm with you on that one. Using Midori in Linux at the moment.

Reply Score: 1

Comment by OSbunny
by OSbunny on Tue 27th Sep 2011 21:28 UTC
OSbunny
Member since:
2009-05-23

Firefox's frequent release schedule is great for bloggers. If you can't think of anything interesting to write about there is always a new firefox release to highlight!

Reply Score: 13

Drastically reduced memory usage?
by darknexus on Tue 27th Sep 2011 22:04 UTC
darknexus
Member since:
2008-07-15

I don't think so. On Windows 7 32-bit, with only one tab open (this very one I'm using to write this), firefox is taking 140 mb of memory. This is with add-ons disabled. It's ridiculous and, while Firefox will probably remain my primary browser until I can get my add-ons on other browsers (Chrome is the closest), Chrome's memory usage with add-ons enabled generally holds at about 30 mb with one tab open. Mozilla's got a long way to go before they can start claiming they've drastically reduced memory consumption. Linux or Mac users, what've your experiences been with ff7 in this area?

Reply Score: 5

lopisaur Member since:
2006-02-27

187MB, with only OSNews open. Linux 2.6.32.34 x86.

Reply Score: 2

Neolander Member since:
2010-03-08

Here, Firefox 4 uses 111 MB on Linux 2.6.35.14 x64, with two tabs opened and French and GB dictionaries as the only extensions. I do not count Flash's memory usage, which is conveniently associated to other processes.

I couldn't update to 5 and 6 because they consider the latest stable Linux Flash Player (10.3.183.10) to be outdated and automatically disable it without a clear way of getting them back. Guess it will be the same with 7...

Also, I wonder if those talking about Chrome's memory usage take into account all processes.

Edited 2011-09-28 05:31 UTC

Reply Score: 1

lemur2 Member since:
2007-02-17

I don't think so. On Windows 7 32-bit, with only one tab open (this very one I'm using to write this), firefox is taking 140 mb of memory. This is with add-ons disabled. It's ridiculous and, while Firefox will probably remain my primary browser until I can get my add-ons on other browsers (Chrome is the closest), Chrome's memory usage with add-ons enabled generally holds at about 30 mb with one tab open. Mozilla's got a long way to go before they can start claiming they've drastically reduced memory consumption. Linux or Mac users, what've your experiences been with ff7 in this area?


http://venturebeat.com/2011/09/27/firefox-memory/

Mozilla released Firefox 7 today, and the new version of makes web browsing faster than ever.

The update is especially helpful for the hardcore web junkies among us who browse with scores of open tabs and browsing sessions that span multiple days.

Firefox 7 reduces memory usage by 20 to 50 percent, which translates to quicker response times and fewer crashes. These improvements constitute the first publicly available implementation of MemShrink, Mozilla’s project focusing on decreasing Firefox’s memory consumption to make browsing faster and more stable.

The hackers at Mozilla are still working on accurate benchmark tests for quantifying Firefox’s memory usage and improvements.

Mozilla says Firefox 7′s improvements should be most noticable to users who leave browser windows open for many hours or days on end, who browse with multiple tabs at once, who open image-heavy pages or pages with large amounts of text, who run Firefox on Windows machines or who use the browser simultaneously with other programs that take a large toll on memory.


Open a few tabs and leave them open, and see what happens.

http://lifehacker.com/5844150/browser-speed-tests-firefox-7-chrome-...

Memory Use (No Extensions)—Winners: Opera and Firefox!

Note that these memory tests were a bit interesting—while IE, Chrome, and Opera all held fast to their memory values, Firefox fluctuated a bit more. It started up higher with Chrome and IE, but then backed off after a few seconds for much lower memory usage.

Memory Use (Five Extensions)—Winners: Opera and Firefox!

While each browser used up a good deal more memory with five extensions attached, Opera still used the least when started up and Firefox used the least once we loaded nine tabs. Again, it fluctuated for a few seconds before it got into first place, but it got there nonetheless.

Overall Scores

Obviously, there's a lot more to browser choice than speed—variety of extensions, customizability, and so on—but when it comes to performance, here's how our favorite browsers. We gave each contender a point value for its placing in each of the above tests, then tallied up the totals and divided them by the total number of points each could have received.

Opera 11.51: 82%
Firefox 7: 73%
Internet Explorer 9: 47.5%
Chrome 14: 43%

Opera's still the speed champion, as usual. The other browsers have surprisingly switched places, though: Firefox, so often looked down upon for its sluggish speeds, has jumped up to #2 with version 7, and Chrome has slowly worked it's way down to last place. Granted, Chrome's inability to complete the CSS test probably pushed it over the edge from 3rd place into 4th. Still, we have seen Chrome slowly gain bloat with each new version, and boy did it feel slow when we ran these tests. Hopefully they can take a hint from Firefox and make a comeback soon.


Edited 2011-09-27 23:56 UTC

Reply Score: 4

tanishaj Member since:
2010-12-22

with only one tab open (this very one I'm using to write this), firefox is taking 140 mb of memory...Chrome's memory usage with add-ons enabled generally holds at about 30 mb with one tab open.


I typically have many, many tabs open. Firefox 7 (although I am on 8 now) uses drastically less memory than Chrome for the same number of tabs.

The use case of "one tab open" is really not interesting to me. Is it really to others? I guess I do not really know.

Reply Score: 2

http:// is gone
by lopisaur on Tue 27th Sep 2011 22:05 UTC
lopisaur
Member since:
2006-02-27
RE: http:// is gone
by Drumhellar on Wed 28th Sep 2011 06:43 UTC in reply to "http:// is gone"
Drumhellar Member since:
2005-07-12

http:// being gone is really no big deal. Many people don't know what it means, it it cleans up the interface for them.

Also. https://, ftp://, and whatever else still show.

Reply Score: 2

RE[2]: http:// is gone
by Lennie on Wed 28th Sep 2011 11:53 UTC in reply to "RE: http:// is gone"
Lennie Member since:
2007-09-22

If it wasn't for all the CA and SSL/TLS protocol problems I would say: everything should be on https://

Reply Score: 2

RE[3]: http:// is gone
by Alfman on Wed 28th Sep 2011 21:36 UTC in reply to "RE[2]: http:// is gone"
Alfman Member since:
2011-01-28

Lennie,


"If it wasn't for all the CA and SSL/TLS protocol problems I would say: everything should be on https://"

Yea, the web should probably default to a low grade encryption, which is extremely fast but deters casual snooping, censorship firewalls, and Phorm-like ISP monitoring.


However, there is one major technical obstacle with SSL that would make this impossible today. HTTPS is not compatible with shared hosting. There are proposed solutions, but they are hacks which leak information and are not supported by today's browsers.


Standard SSL is IP/port based and is not aware of the underlying HTTP protocol, which leads to a chicken/egg problem. HTTPS needs to transfer the certificate before knowing which which domain the client is trying to reach. Therefor, as is, all HTTPS websites would need dedicated IP addresses.

This is a stupid limitation, however I suspect it's due to the fact that SSL was invented a year or so before HTTP/1.1, and all websites needed a dedicated IP address anyways.


The internet is shrouded in legacy designs which dictate how things must be engineered today to work around them. I do wonder if we'll ever get the opportunity to make a clean break?

Reply Score: 2

RE[4]: http:// is gone
by Lennie on Thu 29th Sep 2011 08:09 UTC in reply to "RE[3]: http:// is gone"
Lennie Member since:
2007-09-22

Low grade encryption ? I don't think I've ever seen anyone think that is a good idea. Most people think that just gives a false sense of security.

Could you explain what is wrong with Server Name Indication (SNI) for HTTPS ? Do you think it is wrong to send the website name in the clear ?

If 1 IP-address == 1 HTTPS website then the website people are visiting is easily identified anyway.

It is supported by all clients except for: IE and Safari on Windows XP and the Android developers messed up and didn't add it to Android 2.

Everything else (clients and servers) already supports it for a couple of years. And yes it will take an other few years before Windows XP is dead, but by that time Android 2 is also dead.

Could be IPv6 is widely deployed by then and IPv6-addresses for servers shouldn't be so hard to find. ;-)

Reply Score: 2

RE[5]: http:// is gone
by Alfman on Thu 29th Sep 2011 12:08 UTC in reply to "RE[4]: http:// is gone"
Alfman Member since:
2011-01-28

Lennie,

"Low grade encryption ? I don't think I've ever seen anyone think that is a good idea. Most people think that just gives a false sense of security."

Well, I'm just thinking that a simple encryption would prevent most instances of trivial http data snooping/injection/etc (I'm thinking Phorm or coffee shop/hotel script kiddies). It would be intended to replace clear text HTTP, it would not be intended to replace HTTPS. However you are right that there would be a risk of it being misused.

Unfortunately CPU overhead is often cited as a reason we cannot use HTTPS for everything. CPUs are a lot faster than they used to be, but now we're downloading hundreds of megabytes in a few minutes with a many more users per host. Strong encryption is expensive, and for the bulk of HTTP traffic (like osnews), it's overkill.



"Could you explain what is wrong with Server Name Indication (SNI) for HTTPS?"

I had read that browser support for it is sporadic. That no IE versions on XP support it is fairly major. Also, I don't think most web providers support it either (even if apache does).

"Do you think it is wrong to send the website name in the clear ?"

I have a tough time making up my mind on this one. Yea, it is a shortcoming since it enables things like censorship through deep packet inspection. But then the only way to hide the destination is for the certificate to be transferred out of band (DNS comes up again). I think ideally, we shouldn't leak anything other than the ip/port.

(Just thinking off the cuff, but an alternative idea would be to request a generic certificate up front, and then switch HTTPS certificates mid stream secretly).


"Could be IPv6 is widely deployed by then and IPv6-addresses for servers shouldn't be so hard to find. ;-)"

I think the IPv6 transition will be extremely painful for those of us who still enjoy peer to peer connectivity.

Reply Score: 2

RE[6]: http:// is gone
by Lennie on Thu 29th Sep 2011 14:49 UTC in reply to "RE[5]: http:// is gone"
Lennie Member since:
2007-09-22

Encryption without knowing who you are talking to is pretty much useless. It is like a self-signed certificate on a random website signed by someone you don't know.

This is because a man-in-the-middle attack (which can easily be done on most LAN or WLAN) is possible, he/she can present you with an other (even similair looking) self-signed certificate. It can even be generated on the fly.

Setting up a new HTTPS connection is the slow part. CPU definitely hasn't been a problem in a long time. On a busy server it is more likely there isn't enough 'random data' to able to generate new sessions. So large websites or websites under a (D)DOS attack might need special hardware for that.

Currently we leak the IP/port and it point directly to that one site too. SNI is not less secure in that sense, more secure would have been nice. But it is not backwardcompatible, SNI is.

Reply Score: 2

RE[7]: http:// is gone
by Alfman on Thu 29th Sep 2011 20:07 UTC in reply to "RE[6]: http:// is gone"
Alfman Member since:
2011-01-28

Lennie,

"Encryption without knowing who you are talking to is pretty much useless. It is like a self-signed certificate on a random website signed by someone you don't know."

One nitpick with your statement about anonymous encryption being useless: Unencrypted IP traffic can be altered by a remote attacker who, while blind to your outgoing traffic, can anticipate your requests and spoof the server's response before it responds. Anyone with sufficiently low latency and egress filters disabled can pull it off, but only on insecure channels.


Anyways, this wasn't my point. You had said all web traffic should be encrypted, and I was just replying that low grade encryption would be sufficient for most of the traffic that is sent in the clear today anyways. Military grade encryption is simply overkill. (Did you disagree with this assessment?)


"Setting up a new HTTPS connection is the slow part. CPU definitely hasn't been a problem in a long time. On a busy server it is more likely there isn't enough 'random data' to able to generate new sessions..."

But that's only the case for dedicated hosting. Many/most websites run on shared/virtual hosts which are notoriously over subscribed to deliberately saturate the CPU. Under a strong encryption-everywhere scheme, we're likely going to need more horsepower.

"...But it is not backwardcompatible, SNI is."

If we isolate all the suboptimal software engineering solutions we see today, there's a good chance backwards compatibility is the reason behind them. I sometimes daydream about what we might change if we could from scratch - what a hippy I am. ;)

Reply Score: 2

RE[4]: http:// is gone
by Lennie on Thu 29th Sep 2011 09:19 UTC in reply to "RE[3]: http:// is gone"
Lennie Member since:
2007-09-22

If you want fast encryption everywhere. Chrome-developers seem to be very much interrested in that.

They created SPDY, which is faster than regular HTTP for 98%+ (or something) of the webpages: http://www.chromium.org/spdy

The problem is, it needs a server change. And currently only one browser supports it. Some might still consider it beta.

It seems Amazon might be using SPDY for Amazon Silk: http://aws.amazon.com/amazonsilk-jobs/

Google also tried many ways to mean SSL/TLS faster, but so far only one they found was compatible and helped enough, FalseStart:

http://blog.chromium.org/2011/05/ssl-falsestart-performance-results...

An other way to speed up delivery of secure content is, a Microsoft research project:
http://research.microsoft.com/apps/pubs/default.aspx?id=148963

Which allows for mixing of HTTPS and HTTP.

Where HTTP is used to download images/JavaScript/StyleSheets from a Content Delivery Network (CDN) but the those parts are signed with the same certificate as is used by the website which uses HTTPS.

Microsoft research paper uses the mechanism from Mozilla https://wiki.mozilla.org/Security/CSP to signal which sites are allowed to be loaded from HTTP and should be signed by the main site.

Reply Score: 2

Nightly
by magico on Tue 27th Sep 2011 23:25 UTC
magico
Member since:
2005-07-12

I'm using nightly for some time now, keeping the browser open for days and memory usage stays low. Very stable and the only thing I really miss is silent updates.

Almost all extensions I use (around 10) are compatible.

Good job Mozilla.

Reply Score: 2

End the inflated versioning!
by cmost on Wed 28th Sep 2011 00:47 UTC
cmost
Member since:
2006-07-16

I'm with a lot of users who think these inflated version numbers are absurd. In a few years, we'll be testing Firefox 400 and wondering, WTF!?!? I admire other FOSS projects like Inkscape whose community are conservative with their version numbers because they realize that the code simply isn't mature enough to warrant boundless point releases. It's a mistake to believe that increasing a version number for the sake of version numbers is wise. All it accomplishes is leading users down a disappointing path where they quickly lose faith in the project when expectations don't coincide with reality.

Reply Score: 5

RE: End the inflated versioning!
by lemur2 on Wed 28th Sep 2011 01:27 UTC in reply to "End the inflated versioning!"
lemur2 Member since:
2007-02-17

I'm with a lot of users who think these inflated version numbers are absurd. In a few years, we'll be testing Firefox 400 and wondering, WTF!?!? I admire other FOSS projects like Inkscape whose community are conservative with their version numbers because they realize that the code simply isn't mature enough to warrant boundless point releases. It's a mistake to believe that increasing a version number for the sake of version numbers is wise. All it accomplishes is leading users down a disappointing path where they quickly lose faith in the project when expectations don't coincide with reality.


Chrome has far higher version number than Firefox, and a more rapid release cycle.

Mozilla OTOH has proposed: Extended Support Release.

http://news.cnet.com/8301-30685_3-20109245-264/mozilla-proposes-not...

Under the proposal, Mozilla would issue a new Extended Support Release (ESR) version of Firefox every 30 weeks. That's five times slower than the new rapid-release cycle for regular Firefox, which updates the browser every six weeks. And each version would be supported for 42 weeks under the proposal.

With the ESR proposal, Mozilla is trying to have it both ways, modernizing its development process without abandoning slower-moving customers. If it moves too slowly, it risks losing its edge with early adopters who already have found Google's Chrome appealing. If it moves too fast, it risks driving slower-moving organizations into the arms of Microsoft's Internet Explorer.

The company, while trying to accommodate the slower-moving customers without having to spin up a huge new support operation, is as convinced as ever that the rapid-release program is the best way forward.


This proposal addresses your faux-issue whilst still allowing a rapid development cycle.

Enjoy.

Reply Score: 4

42 Weeks only?
by shotsman on Wed 28th Sep 2011 05:20 UTC in reply to "RE: End the inflated versioning!"
shotsman Member since:
2005-07-22

A Long term, sorry extended support release should have at least a 2 year lifespan.

Ok, I know that 42 is the answer to life etc but obviously someone at Mozilla thinks that life is too short. And, by a long way.

Reply Score: 2

RE: 42 Weeks only?
by lemur2 on Wed 28th Sep 2011 06:41 UTC in reply to "42 Weeks only?"
lemur2 Member since:
2007-02-17

A Long term, sorry extended support release should have at least a 2 year lifespan. Ok, I know that 42 is the answer to life etc but obviously someone at Mozilla thinks that life is too short. And, by a long way.


Here is the Extended Support Release (ESR) proposal wiki:

https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal

Please contribute your undoubtedly invaluable ideas on how Firefox can be more responsive to the changing web than IE, yet less volatile than Chrome, in order to satisfy everybody.

Just quietly, it looks to me as though the wiki, so far, has a far better proposal than you do.

Reply Score: 2

Graphics Acceleration
by tomcat on Wed 28th Sep 2011 01:15 UTC
tomcat
Member since:
2006-01-06

Firefox 7 apparently uses Direct2D on Vista and Win7. Anybody do any comparisons with Firefox 6?

Reply Score: 2

RE: Graphics Acceleration
by lemur2 on Wed 28th Sep 2011 01:32 UTC in reply to "Graphics Acceleration"
lemur2 Member since:
2007-02-17

Firefox 7 apparently uses Direct2D on Vista and Win7. Anybody do any comparisons with Firefox 6?


Graph here:
http://www.ghacks.net/2011/08/16/firefox-7-may-ship-with-new-graphi...

Discussion here:
http://www.basschouten.com/blog1.php

Earlier technical discussion here:

http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-projec...

Edited 2011-09-28 01:39 UTC

Reply Score: 3

RE[2]: Graphics Acceleration
by tomcat on Wed 28th Sep 2011 06:42 UTC in reply to "RE: Graphics Acceleration"
tomcat Member since:
2006-01-06

"[q]Firefox 7 apparently uses Direct2D on Vista and Win7. Anybody do any comparisons with Firefox 6?


Graph here:
http://www.ghacks.net/2011/08/16/firefox-7-may-ship-with-new-graphi...

Discussion here:
http://www.basschouten.com/blog1.php

Earlier technical discussion here:

http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-projec...
"

Wow, such a shame that Linux users can't get these perf gains...

Edited 2011-09-28 06:43 UTC

Reply Score: 2

RE[3]: Graphics Acceleration
by lemur2 on Wed 28th Sep 2011 07:04 UTC in reply to "RE[2]: Graphics Acceleration"
lemur2 Member since:
2007-02-17

Wow, such a shame that Linux users can't get these perf gains


For Firefox 7 the new Azure graphics works only for Canvas elements, and only on Win 7 and Vista. Mozilla have written the Direct2D backend for Azure first, and they are still working on the OpenGL and Direct3D backends. This is perfectly reasonable, given the relative numbers of Windows users of Firefox compared to the number of Linux users.

This is somewhat similar to the situation that occurred with hardware acceleration, wherein the Windows version had hardware acceleration in Firefox 4 but this did not appear in the Linux version until Firefox 6.

Hence the beauty of the Firefox rapid release cycle. One can expect the Linux version to have Azure graphics improvements via an OpenGL backend in a few months time.

Thanks for your concern, but it really wasn't necessary.

Edited 2011-09-28 07:09 UTC

Reply Score: 4

RE[4]: Graphics Acceleration
by tomcat on Wed 28th Sep 2011 23:25 UTC in reply to "RE[3]: Graphics Acceleration"
tomcat Member since:
2006-01-06

Firefox devs made the right choice. Vista/Windows is by far their largest segment of market share, and Direct2D is ready now; whereas, an implementation built on OpenGL/Linux will be an ongoing work in progress....

Reply Score: 3

RE[5]: Graphics Acceleration
by lemur2 on Wed 28th Sep 2011 23:39 UTC in reply to "RE[4]: Graphics Acceleration"
lemur2 Member since:
2007-02-17

Firefox devs made the right choice. Vista/Windows is by far their largest segment of market share, and Direct2D is ready now; whereas, an implementation built on OpenGL/Linux will be an ongoing work in progress....


Not to worry, I can wait 12 weeks for it to appear in Linux versions of Firefox. With a bit of luck I might have to wait only 6 weeks.

Reply Score: 2

RE[6]: Graphics Acceleration
by tomcat on Thu 29th Sep 2011 18:14 UTC in reply to "RE[5]: Graphics Acceleration"
tomcat Member since:
2006-01-06

"Firefox devs made the right choice. Vista/Windows is by far their largest segment of market share, and Direct2D is ready now; whereas, an implementation built on OpenGL/Linux will be an ongoing work in progress....


Not to worry, I can wait 12 weeks for it to appear in Linux versions of Firefox. With a bit of luck I might have to wait only 6 weeks.
"

Alas, the perf won't be as good.

Reply Score: 2

RE[3]: Graphics Acceleration
by Soulbender on Thu 29th Sep 2011 14:39 UTC in reply to "RE[2]: Graphics Acceleration"
Soulbender Member since:
2005-08-18

Wow, such a shame that Linux users can't get these perf gains...


Yeah, shame we can't show a fishbowl with 1500 fish in it smoothly....
Seems to mostly be useful for really intense HTML5 canvas games of which there are...not many. By the time there are,the OGL support is probably done.

Reply Score: 3

Memory usage improved!
by ccraig13 on Wed 28th Sep 2011 01:49 UTC
ccraig13
Member since:
2011-05-31

I really don't use FF much anymore, but I did a test (12 tabs) and the new version dropped from 350MB to 250MB memory usage. Not too shabby!

I'd also like to note that my Chrome is using 150MB but also has a 36MB render process for each tab I have open (18, non with flash) and six worker processes using 20MB each. Total 918MB!

This is not a scientific comparison by any means since the tabs are not the same on each, but they are all just non flash web pages. Even with all that memory being used, chrome's UI still responds faster that FF's.

I'm running OS X 10.6

Reply Score: 1

RE: Memory usage improved!
by _xmv on Wed 28th Sep 2011 03:11 UTC in reply to "Memory usage improved!"
_xmv Member since:
2008-12-09

yeah that's because chrome uses separate processes for everything. more memory but more responsive.
firefox still uses threads (excepts for plugins), less memory, but hard to get as responsive. that being said its rare that the UI slows down.

Reply Score: 4

RE[2]: Memory usage improved!
by lemur2 on Wed 28th Sep 2011 03:21 UTC in reply to "RE: Memory usage improved!"
lemur2 Member since:
2007-02-17

yeah that's because chrome uses separate processes for everything. more memory but more responsive. firefox still uses threads (excepts for plugins), less memory, but hard to get as responsive. that being said its rare that the UI slows down.


http://lifehacker.com/5844150/browser-speed-tests-firefox-7-chrome-...

"Obviously, there's a lot more to browser choice than speed—variety of extensions, customizability, and so on—but when it comes to performance, here's how our favorite browsers. We gave each contender a point value for its placing in each of the above tests, then tallied up the totals and divided them by the total number of points each could have received.

Opera 11.51: 82%
Firefox 7: 73%
Internet Explorer 9: 47.5%
Chrome 14: 43%

Opera's still the speed champion, as usual. The other browsers have surprisingly switched places, though: Firefox, so often looked down upon for its sluggish speeds, has jumped up to #2 with version 7, and Chrome has slowly worked it's way down to last place. Granted, Chrome's inability to complete the CSS test probably pushed it over the edge from 3rd place into 4th. Still, we have seen Chrome slowly gain bloat with each new version, and boy did it feel slow when we ran these tests. Hopefully they can take a hint from Firefox and make a comeback soon. "


Edited 2011-09-28 03:38 UTC

Reply Score: 2

RE: Memory usage improved!
by WereCatf on Wed 28th Sep 2011 07:03 UTC in reply to "Memory usage improved!"
WereCatf Member since:
2006-02-15

I really don't use FF much anymore, but I did a test (12 tabs) and the new version dropped from 350MB to 250MB memory usage. Not too shabby!


I've got 16 tabs open ATM and I'm getting 370Mb, and that's with a few addons, too. That's a lot less than it previously was, I think it hovered at around 600-700 megabytes.

So, memory-usage-wise this update atleast was good.

Reply Score: 3

I've been running FF7 since it hit beta
by smitty on Wed 28th Sep 2011 03:42 UTC
smitty
Member since:
2005-10-13

And it's a big improvement over 6.

I'm getting 15% less memory at launch, and 30% less after some time goes by.

More importantly, it stays much more responsive over time. It's still not quite at Chrome-like levels of responsiveness, but it's getting much closer.

Oh, and to all the people complaining about version numbers: just go away and use another browser if you hate it so much. The whole point Mozilla is making is that you shouldn't care what the version is, just like with Chrome. They are working on making it silently update, that just hasn't come out yet.

I, for one, am very, very happy that these improvements that have come out over the last few months are available. Otherwise, we would all still be stuck on Firefox 4 for the next 12 months, and in comparison with the current version that would SUCK.

Edited 2011-09-28 03:46 UTC

Reply Score: 5

Comment by Anonymous Penguin
by Anonymous Penguin on Wed 28th Sep 2011 15:24 UTC
Anonymous Penguin
Member since:
2005-07-06

Today I accepted the upgrade to Thunderbird 7, and nothing visible has changed.

However when it comes to Firefox I am still using 3.6.20.

I hate the frequent, meaningless interface changes and my add-ons being broken.

Reply Score: 2

RE: Comment by Anonymous Penguin
by lemur2 on Wed 28th Sep 2011 22:48 UTC in reply to "Comment by Anonymous Penguin"
lemur2 Member since:
2007-02-17

Today I accepted the upgrade to Thunderbird 7, and nothing visible has changed. However when it comes to Firefox I am still using 3.6.20. I hate the frequent, meaningless interface changes and my add-ons being broken.


You can set the interface back to the way it was for 3.6.x, it isn't even difficult, it takes only a few clicks.

You can use the addon compatibility reporter to enable addons which have not updated their compatibility information. Most of them will work. Most of them will have a new version available anyway, you just have to let them update.

You are missing out on a great deal by not changing to Firefox 7. Firefox 7 beats the socks off Firefox 3.6.20.

Reply Score: 2

Had serious problems with v6
by saimon69 on Wed 28th Sep 2011 16:03 UTC
saimon69
Member since:
2008-10-26

With v6 almost ALL ajax in the web site of the company where i work (that uses jQuery 1.3.2/1.4.3 for scripts compatibility) were not performing; or even performing the first time then stop working; at first it seemed was firebug because things seemed to perform just fine without and i upgraded it to a beta version, but later things were still not working; solution: had to downgrade to v3.6 in order to continue develop; a colleague of mine is still using v4 and i see that sometimes some styles break on a wordpress theme (in sidebars titles get bigger and misplaced).

Reply Score: 1

RE: Had serious problems with v6
by lucas_maximus on Wed 28th Sep 2011 18:10 UTC in reply to "Had serious problems with v6"
lucas_maximus Member since:
2009-08-18

I stopped using Firefox for development entirely. Using Chrome at the moment and obviously checking that stuff works in IE, Firefox, Safari as I go along ... But none of them are that good IMO.

Chrome is the best ... but I am worried I will end up "coding for webkit" rather than coding cross browser.

Edited 2011-09-28 18:14 UTC

Reply Score: 2

Easy fix
by Bounty on Wed 28th Sep 2011 16:21 UTC
Bounty
Member since:
2006-09-18

They should just add "1." at the beginning of the version number, then everyone worried about version creep can settle down. Of course that means they should also deploy the update as an update and not a full version.

I dislike the removal of http. Now when I leave, come back, look at the address bar and see a hostname, I have to think, hmmm what am I looking at. Lets see, this is Firefox, ohh right, it only hides parts of the URL when it's http traffic, and I don't see http, so it must be http (not https or something else.) It's like only hiding certain file extensions. I beg for consistent behavior.

Reply Score: 2

There is a plan to improve extensions
by smitty on Wed 28th Sep 2011 18:29 UTC
smitty
Member since:
2005-10-13

Starting with Firefox 8.

The extensions will start being treated as compatible by default, with certain one blacklisted if they are known to cause problems.

FF8 will bring a way to manage the addons installed outside the browser as well, like those Java addons.

Eventually the goal is to get all addons using the new JetPack API which will remain more stable, and allow for restartless installations.

Edited 2011-09-28 18:30 UTC

Reply Score: 2

Alfman Member since:
2011-01-28

smitty,

"Starting with Firefox 8. The extensions will start being treated as compatible by default, with certain one blacklisted if they are known to cause problems."

I'm running FF 9 Nightly alpha builds, and almost every single update breaks some addons. Just 5 minute ago I was prompted to update, but warned that it would break some of my addons.

http://www.screenshots.cc/photos/medium/50180-a1w8g.jpg
http://www.screenshots.cc/photos/medium/50179-nhsgj.jpg

If what you say is true, I'm curious why they haven't applied this fix to FF9 Alpha yet. Mozilla hosing addons all the time sucks, both as a user and as a developer.

Reply Score: 2

lemur2 Member since:
2007-02-17

smitty, "Starting with Firefox 8. The extensions will start being treated as compatible by default, with certain one blacklisted if they are known to cause problems." I'm running FF 9 Nightly alpha builds, and almost every single update breaks some addons. Just 5 minute ago I was prompted to update, but warned that it would break some of my addons. http://www.screenshots.cc/photos/medium/50180-a1w8g.jpg http://www.screenshots.cc/photos/medium/50179-nhsgj.jpg If what you say is true, I'm curious why they haven't applied this fix to FF9 Alpha yet. Mozilla hosing addons all the time sucks, both as a user and as a developer.


Here is a rational discussion of this:

http://blog.fligtar.com/2011/09/26/add-on-compatibility-progress-pl...

Here is the money quote:
"Compatibility-breaking changes in Firefox have been minimal in the first four 6-week development cycles, with the exception of two larger changes that were reverted because of their larger impact. Jorge has posted detailed guides to changes that affect add-on developers for each of those releases (5 & 6, 7, 8), and Firefox developers are often coming to us to discuss the impact of their changes on add-ons.

We’ve automatically bumped thousands of add-ons for each Aurora version and emailed developers with the results of our compatibility scanning. When Firefox 6 launched, 97% of add-ons compatible with Firefox 5 were still compatible with 6. And we’re on track to launch Firefox 7 tomorrow with 99% compatibility from 6."

99% compatibility. Thousands of add-ons automatically bumped.

I think that says it all with respect to this issue.

It seems there is some kind of Internet meme agenda to try to make a mountain out of this Firefox extension compatibility molehill.

Reply Score: 2

smitty Member since:
2005-10-13

To be fair, most of the issues with incompatibilities are with addons not hosted by Mozilla. Those 97-99% rates go way down in the real world.

Of course, extensions like the ones Java, Microsoft, and others add usually aren't very useful anyway.

Reply Score: 2

lemur2 Member since:
2007-02-17

To be fair, most of the issues with incompatibilities are with addons not hosted by Mozilla. Those 97-99% rates go way down in the real world. Of course, extensions like the ones Java, Microsoft, and others add usually aren't very useful anyway.


You have no support for this claim.

To be fair, "Compatibility-breaking changes in Firefox have been minimal in the first four 6-week development cycles".

To be fair, 99% of a large sample set of typical add-ons are found to be compatible (and marked as such via a simple automated process).

To be fair, all that is normally required to make an add-on which is not hosted by Mozilla compatible is to mark it as such by updating the compatibility data contained with the add-on.

Edited 2011-09-29 01:47 UTC

Reply Score: 2

smitty Member since:
2005-10-13

smitty,

"Starting with Firefox 8. The extensions will start being treated as compatible by default, with certain one blacklisted if they are known to cause problems."

I'm running FF 9 Nightly alpha builds, and almost every single update breaks some addons. Just 5 minute ago I was prompted to update, but warned that it would break some of my addons.

http://www.screenshots.cc/photos/medium/50180-a1w8g.jpg
http://www.screenshots.cc/photos/medium/50179-nhsgj.jpg

If what you say is true, I'm curious why they haven't applied this fix to FF9 Alpha yet. Mozilla hosing addons all the time sucks, both as a user and as a developer.


You put my words in quotes like you were taking them exactly, but that's not what i said at all.

I said, they were going to start addressing the addon issue starting with FF8.

Then, separately, I said there was a plan to make addons compatible by default. Although I'll admit i worded it a bit unclearly. I don't know when that is supposed to take affect. Perhaps FF10, which is due to go into Aurora any time now.

The automatic compatibility also won't apply to any binary extensions, but I think the vast majority would be included.

Reply Score: 2

lemur2 Member since:
2007-02-17

You put my words in quotes like you were taking them exactly, but that's not what i said at all. I said, they were going to start addressing the addon issue starting with FF8. Then, separately, I said there was a plan to make addons compatible by default. Although I'll admit i worded it a bit unclearly. I don't know when that is supposed to take affect. Perhaps FF10, which is due to go into Aurora any time now. The automatic compatibility also won't apply to any binary extensions, but I think the vast majority would be included.


I'm sorry, I was too lazy there. I wasn't commenting on your words, I was making a comment on the claim that "almost every single update breaks some addons".

This wasn't your claim.

While it may or may not be true, the way it was worded gives an utterly false impression of the scope of the problem. To get a real handle on the scope of the problem, a more representative statement is that "interface changes are minimal, and 99% of add-ons are compatible without requiring any change".

That was my point. I should have removed the words quoted which came from you, because indeed your words had nothing to do with it.

Edited 2011-09-29 01:45 UTC

Reply Score: 2

smitty Member since:
2005-10-13

I was actually replying to Alfman and not you - unless you are the same person?

I think we actually agree on most things, as I was getting my info from that same link you posted earlier.

What I was specifically referring to was this:

And it was quite eye-opening when I learned that only 25% of the 600 million add-ons in use every day in Firefox 4 and later are active on AMO. That means at least 75% of add-ons aren’t getting the benefits of the automatic compatibility system we created, as well as the security and quality reviews that hosted add-ons receive. When we created the compatibility plan for the new development cycles, we weren’t aware that so many add-ons wouldn’t even be affected by it.


So while the CURRENT system of auto-updating all Mozilla hosted addons may be hitting a 97% success rate, lots of Google Toolbar extensions are not included in that. It's true that they generally just have to bump the version number to fix it - but that is something these 3rd parties are not doing in a timely fashion. Therefore, in the future the system will change to always assume the addon will work which should fix this problem.

Reply Score: 2

lemur2 Member since:
2007-02-17

I think we actually agree on most things, as I was getting my info from that same link you posted earlier. What I was specifically referring to was this: "And it was quite eye-opening when I learned that only 25% of the 600 million add-ons in use every day in Firefox 4 and later are active on AMO. That means at least 75% of add-ons aren’t getting the benefits of the automatic compatibility system we created, as well as the security and quality reviews that hosted add-ons receive. When we created the compatibility plan for the new development cycles, we weren’t aware that so many add-ons wouldn’t even be affected by it.

So while the CURRENT system of auto-updating all Mozilla hosted addons may be hitting a 97% success rate, lots of Google Toolbar extensions are not included in that. It's true that they generally just have to bump the version number to fix it - but that is something these 3rd parties are not doing in a timely fashion. Therefore, in the future the system will change to always assume the addon will work which should fix this problem.
"

Exactly so.

The only thing I would add to your erudite summary is that, since 99% of the 25% of extentions which are active on AMO are compatible between Firefox versions, this is easily a large enough sample to infer that roughly 99% of the remaining 75% of extensions which are NOT hosted on AMO should likewise be compatible.

I wholeheartedly agree that essentially "they generally just have to bump the version number to fix it".

Where we perhaps may differ is that I would contend that this is not an issue for Firefox or Mozilla, it is rather an issue for users and providers of extensions for Firefox outside of Mozilla. Users should in the first instance get the addon compatibility reporter and mark their recalcitrant non-AMO extension as compatible. In 99% of cases that alone will do the trick.

Providers of extensions who want to make a good impression with their users should take that teeny, tiny bit of effort required and mark their extension as compatible prior to a new version of Firefox becoming available. I would be surprised if most reputable providers of extensions did not in fact do this.

Finally, perhpas what would be the most help of all, would be for users to understand that if they get an extension outside of AMO then it won't update by itself. The user will have to get a new copy of the extension from wherever they got it in the first place.

Reply Score: 2

Alfman Member since:
2011-01-28

smitty,

"So while the CURRENT system of auto-updating all Mozilla hosted addons may be hitting a 97% success rate, lots of Google Toolbar extensions are not included in that."

I think that success rate is only true of release versions. With the alpha version of FF, I know firsthand that disabled plugins have been much worse. However as you indicate, this is because addon developers aren't keeping the version numbers in synch with mozilla's alpha builds, not because a genuine incompatibility exists.


"Therefore, in the future the system will change to always assume the addon will work which should fix this problem."

I hope so, plugins should have never been tethered to FF version numbers in the first place. As long as the API is compatible, the plugin should load.

Reply Score: 2

smitty Member since:
2005-10-13

I think that success rate is only true of release versions. With the alpha version of FF, I know firsthand that disabled plugins have been much worse. However as you indicate, this is because addon developers aren't keeping the version numbers in synch with mozilla's alpha builds, not because a genuine incompatibility exists.

Addon developers who host with Mozilla no longer even need to update the version numbers. Mozilla is doing that automatically, then testing, and reverting back on the couple of percent that are broken.

I'm sure they don't do that for the Alphas, though, so you aren't seeing the benefit.

Reply Score: 2

lemur2 Member since:
2007-02-17

Addon developers who host with Mozilla no longer even need to update the version numbers. Mozilla is doing that automatically, then testing, and reverting back on the couple of percent that are broken.


I'm sure that this is a source of confusion for people.

Almost all of the addons hosted at addons.mozilla.org (AMO) are automatically compatible. Users who get their addons from there will not see a problem. The addons will automatically update on the first run of an updated Firefox.

User who accept or install "addons from all over" will see at least some of their addons disabled after an update of Firefox. Many will simply assume that the Firefox update has "broken" their addons, without realising that if they update Firefox they have to update their non-AMO addons also. Manually.

Mozilla has no control over "addons from all over". Mozilla can't check an addon for compatibility if it is not known to Mozilla. Firefox has to assume that an addon which says it is compatible only with an earlier version of Firefox is not compatible with the newer version, even though it very probably is compatible.

Reply Score: 2

Alfman Member since:
2011-01-28

smitty,

"You put my words in quotes like you were taking them exactly, but that's not what i said at all."

I did quote you exactly, I added the quote to provide context. If I misinterpreted your post, then I apologize.

"I said, they were going to start addressing the addon issue starting with FF8. Then, separately, I said there was a plan to make addons compatible by default. Although I'll admit i worded it a bit unclearly. I don't know when that is supposed to take affect. Perhaps FF10, which is due to go into Aurora any time now."

I have no idea what you are saying here, what does it mean to start addressing issues in FF8, but not have it go into affect until FF10? I honestly don't know what you mean.

Reply Score: 2

smitty Member since:
2005-10-13

I did quote you exactly, I added the quote to provide context. If I misinterpreted your post, then I apologize.

Ok, sorry, let me explain it a little better. I went back and realized my post was garbled a lot more than i had originally thought.

My thoughts started in the title:
There is a plan to improve extensions

And then continued on the next line:
Starting with Firefox 8.

That was one sentence.

Then, in a new paragraph, i said:
The extensions will start being treated as compatible by default, with certain one blacklisted if they are known to cause problems.

That's not happening in FF8. Probably not in 10 either, but maybe 11. However, it is the current plan for dealing with extensions in the medium term.

Then I made a new paragraph, indicating a new thought:
FF8 will bring a way to manage the addons installed outside the browser as well, like those Java addons.

Mentioning what it would start doing in FF8. This was just to indicate that movement was starting on the whole extensions issue starting in FF8, and would continue in the future in other ways.

And then i finished with another new paragraph mentioning some of the long term plans that would happen in later releases.
Eventually the goal is to get all addons using the new JetPack API which will remain more stable, and allow for restartless installations

Reply Score: 2

Neolander Member since:
2010-03-08

Here's what the current release plan says.

In firefox 8, they begin warning the user on update if an add-on is incompatible, allowing them to cancel the update.

Starting from firefox 10, add-ons will begin to default to "compatible".

See : https://wiki.mozilla.org/Features/Release_Tracking

Reply Score: 1

Alfman Member since:
2011-01-28

Neolander,

"In firefox 8, they begin warning the user on update if an add-on is incompatible, allowing them to cancel the update."

This is how FF9 works too.

"Starting from firefox 10, add-ons will begin to default to 'compatible'."

I'll probably cross my fingers and make the jump.
Here is a direct link to the new compatibility feature:

https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compati...

Reply Score: 2

Neolander Member since:
2010-03-08

Firefox 10 indeed : https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compati...

(By the way, I strongly recommend having a regular look to https://wiki.mozilla.org/Features/Release_Tracking, it's nice of Mozilla to present the planned evolutions of each release so much in advance)

Reply Score: 1

Mingw...
by fithisux on Thu 29th Sep 2011 09:37 UTC
fithisux
Member since:
2006-01-22

I wish Firefox could be installed on windows with a mingw/mingw-i686-w64 compilation (preferably with gtk+3 and gail) to move away from windows SDK, and without that nspr precompiled lib (also should be compilable from source). Cmake or configure could be an option.
This would be an also cool announcement for me. I do not have VS and I do not intend to use it.

The new release also is a memory hog but less than previous 6.x series. It is an improvement.

Reply Score: 2

RE: Mingw...
by lemur2 on Thu 29th Sep 2011 09:50 UTC in reply to "Mingw..."
lemur2 Member since:
2007-02-17

The new release also is a memory hog but less than previous 6.x series. It is an improvement.


http://lifehacker.com/5844150/browser-speed-tests-firefox-7-chrome-...

Memory Use (No Extensions)—Winners: Opera and Firefox!

http://cache.gawkerassets.com/assets/images/17/2011/09/memorynoex.p...

Memory Use (Five Extensions)—Winners: Opera and Firefox!

http://cache.gawkerassets.com/assets/images/17/2011/09/memoryfiveex...

(Note that IE9 doesn't have extensions)

If the new release is a memory hog, then all current popular browsers except possibly Opera are even more of a memory hog.

Reply Score: 2

...and still no 64-bit on Windows
by BallmerKnowsBest on Thu 29th Sep 2011 14:59 UTC
BallmerKnowsBest
Member since:
2008-06-02

All Firefox vs. Chrome dick-measuring is pointless, both of them are amateur-hour toys given the lack of 64-bit support on Windows. For all of the knee-jerk, anti-MS whining about how far behind IE is, there have been 64-bit versions available since at least IE7. C'mon guys, at least try to keep up LOL!

Until Google or Mozilla manage to reach at least the same level that IE was at 3-4 years ago, I'll stick the vastly-superior IE 10 thankyouverymuch.

Reply Score: 2

twitterfire Member since:
2008-09-11

All Firefox vs. Chrome dick-measuring is pointless, both of them are amateur-hour toys given the lack of 64-bit support on Windows. For all of the knee-jerk, anti-MS whining about how far behind IE is, there have been 64-bit versions available since at least IE7. C'mon guys, at least try to keep up LOL!

Until Google or Mozilla manage to reach at least the same level that IE was at 3-4 years ago, I'll stick the vastly-superior IE 10 thankyouverymuch.


I think that Chrome 32 bit is faster than any IE version, be it 32 or 64 bits. It has sandbox, lots of addons including adblock, so for many people Chrome is the best browser.

Reply Score: 2

lemur2 Member since:
2007-02-17

"All Firefox vs. Chrome dick-measuring is pointless, both of them are amateur-hour toys given the lack of 64-bit support on Windows. For all of the knee-jerk, anti-MS whining about how far behind IE is, there have been 64-bit versions available since at least IE7. C'mon guys, at least try to keep up LOL! Until Google or Mozilla manage to reach at least the same level that IE was at 3-4 years ago, I'll stick the vastly-superior IE 10 thankyouverymuch.
I think that Chrome 32 bit is faster than any IE version, be it 32 or 64 bits. It has sandbox, lots of addons including adblock, so for many people Chrome is the best browser. "

Your information is out of date. Chrome is no longer faster than IE9. Firefox 7 is faster than both Chrome and IE9, and it has vastly more addons.

I actually run Firefox 7 64-bit version under Linux, so I'm not exactly sure what the issue is with the lack of a 64-bit version of Firefox for Windows. Perhaps it is the same issue that makes 64-bit IE9 have abysmal performance.

Edited 2011-09-30 00:58 UTC

Reply Score: 2

sorpigal Member since:
2005-11-02

Since when do people still use Windows, much less run 64bit Windows?

Reply Score: 2

BallmerKnowsBest Member since:
2008-06-02

Since when do people still use Windows, much less run 64bit Windows?


Wow. I'd heard that there are people who spend so much time on slashdot that they start believing their little echo-chamber actually reflects the real world... but this is the first time I've actually encountered one.

I have to thank you for the good laugh, though. The size of Windows' userbase mocked by an advocate of Linux, when even Vista (the least-successful Windows release ever) has almost 6 times as many users? LOL!

Reply Score: 2

smitty Member since:
2005-10-13

All Firefox vs. Chrome dick-measuring is pointless, both of them are amateur-hour toys given the lack of 64-bit support on Windows. For all of the knee-jerk, anti-MS whining about how far behind IE is, there have been 64-bit versions available since at least IE7. C'mon guys, at least try to keep up LOL!

Until Google or Mozilla manage to reach at least the same level that IE was at 3-4 years ago, I'll stick the vastly-superior IE 10 thankyouverymuch.

IE9 64 bit support sucks - they didn't integrate their new javascript engine with it, which means you get comparable performance to Firefox from 5 years ago.

Has IE10 fixed that? I know Mozilla setup some Win64 test machines somewhat recently, so that support may be coming soon.

Reply Score: 2

Firefox on mobile
by twitterfire on Thu 29th Sep 2011 16:28 UTC
twitterfire
Member since:
2008-09-11

Firefox on Android uses the most memory and is the slowest Android browser. I hope they can fix that.

Reply Score: 2

Acid3 test
by unoengborg on Thu 29th Sep 2011 17:22 UTC
unoengborg
Member since:
2005-07-06

It looks like firefox now passes the acid3 test. Not that it matters much for real use. I can't remember any site that have looked bad in previous version either, but still nice that it now passes.

Reply Score: 2

RE: Acid3 test
by lemur2 on Thu 29th Sep 2011 23:35 UTC in reply to "Acid3 test"
lemur2 Member since:
2007-02-17

It looks like firefox now passes the acid3 test. Not that it matters much for real use. I can't remember any site that have looked bad in previous version either, but still nice that it now passes.


Actually, it was the acid3 test that changed. The part of the acid3 test that Friefox used to fail was SVG fonts. SVG fonts is basically broken. Chrome, Safari and Opera paid lip service to it anyway, and implemented just enough of SVG fonts to pass the acid3 check of it. Firefox and IE9 didn't do that.

What Microsoft and Mozilla actually did was come up with a better solution. They collaborated! The result was WOFF.

http://en.wikipedia.org/wiki/Web_Open_Font_Format

"The format has received the backing of many of the main font foundries and has been supported by Firefox since version 3.6, by Google Chrome since version 6.0, and by Opera in version 11.10. Microsoft added full support for WOFF in the third platform preview of Internet Explorer 9, and Presto supports WOFF as of version 2.7.81. WebKit development builds support WOFF, and support for it has been announced on Mac OS X Lion's Safari."

Given the widespread support for WOFF and the fact that it is now in the process of becoming a W3C recommendation in its own right, SVG Fonts are effectively redundant. No longer required.

Since they are basically irrelevant, the people who wrote the acid3 tests removed the tests for SVG fonts.

http://en.wikipedia.org/wiki/Acid3

"According to Mozilla employee Robert O'Callahan, Firefox does not support SVG fonts because Mozilla considers WOFF a superior alternative to SVG fonts. Another Mozilla engineer Boris Zbarsky claims that the subset of the specification implemented in Webkit and Opera gives no benefits to web authors or users over WOFF, and asserts that implementing SVG Fonts fully in a web browser is hard because it was "not designed with integration with HTML in mind".

"On September 17th, 2011, Ian Hickson announced an update to the Acid3 test. He claims that removing the parts of the test that check the implementation of features likely to be removed or heavily modified in future specifications will allow those specifications to change in the way they should, without regard to what Acid3 tests. As a result, the latest versions of Firefox and Internet Explorer achieved a score of 100/100 on Acid3."

Edited 2011-09-29 23:39 UTC

Reply Score: 2