Firefox 8 released [LWN.net]

The announcement of a new Firefox release on the Mozilla blog does not mention a version number anywhere, but the actual release calls itself "Firefox 8." The headline feature appears (sadly) to be a Twitter search option. Beyond that, this release disables add-ons by third-party programs and adds a "load tabs on demand" preference option along with improved performance and a number of security fixes; see the release notes for details.

to post comments

Thunderbird too

Posted Nov 8, 2011 20:25 UTC (Tue) by proski (guest, #104) [Link] (44 responses)

Thunderbird 8.0 has also been released. However, the latest version listed on http://www.mozilla.org/projects/thunderbird/ is still 3.1 and the next version is said to be 3.3. What a mess! I wonder if anyone maintains Thunderbird webpages these days.

Thunderbird too

Posted Nov 8, 2011 21:18 UTC (Tue) by rahvin (guest, #16953) [Link] (43 responses)

I'd just like to know why every release is a major number increment. At the rate they are going we are going to be at Firefox 39 in 3 years. Why couldn't we stick with the major.minor release numbering where only major upgrades got a new major number?

Thunderbird too

Posted Nov 8, 2011 21:28 UTC (Tue) by intgr (subscriber, #39733) [Link]

Well, they want to get rid of version numbers entirely. Obviously it's a lot easier to justify that when you have a three-digit version number. ;)

Major number increments

Posted Nov 8, 2011 21:37 UTC (Tue) by pr1268 (guest, #24648) [Link] (1 responses)

It's all a marketing gimmick. Consider Sun's Solaris release numbering scheme, the Linux Kernel major number jump, or even the distro I use (Slackware) jumping 3 version numbers in a single release (4 → 7), I don't think software version numbers are relevant any longer. </jaded comment>

Major number increments

Posted Nov 12, 2011 15:31 UTC (Sat) by gerv (guest, #3376) [Link]

Given that, as the article notes, the marketing isn't using version numbers any more, how can you say that the version number scheme is a marketing gimmick?

Gerv

Thunderbird too

Posted Nov 8, 2011 21:38 UTC (Tue) by endecotp (guest, #36428) [Link] (3 responses)

> I'd just like to know why every release is a major number increment.

To keep up with the other browsers. IE has got to version 9, Chrome is at something like 15. Only a crazy person would install a browser that was only at version 4-and-a-bit - that's only half as much as IE.

Just be grateful that the browsers still use numbers. Most things now seem to use textual version names like "Ice Cream Wombat". Presumably the idea is that you can tell that one name is better than another based on some measure of cuteness or something, though that seems to need a level of cultural awareness that I lack.

Thunderbird too

Posted Nov 8, 2011 22:05 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> Only a crazy person would install a browser that was only at version 4-and-a-bit - that's only half as much as IE.

In that case, everyone needs to catch up then. uzbl is at version 2011.10.01. ;)

Thunderbird too

Posted Nov 9, 2011 12:33 UTC (Wed) by fghorow (subscriber, #5229) [Link]

I think maybe that should be "Ice Cream Weasel", no? ;-)

Thunderbird too

Posted Nov 10, 2011 23:52 UTC (Thu) by kripkenstein (guest, #43281) [Link]

>> I'd just like to know why every release is a major number increment.

> To keep up with the other browsers. IE has got to version 9, Chrome is at something like 15.

Would you prefer that Chrome and Firefox call their 6-week updates minor releases, even though they do break things in these releases? Honest question. If Chrome and Firefox did that, we would have the exact opposite complaint ("Why does Chrome 5.2 break websites that worked on Chrome 5.1?" etc.).

Thunderbird too

Posted Nov 8, 2011 23:41 UTC (Tue) by GhePeU (subscriber, #56133) [Link]

No, with 8 they caught up with the Fibonacci sequence, they'll get to Firefox 55 in 6 months.

Thunderbird too

Posted Nov 8, 2011 23:50 UTC (Tue) by raven667 (guest, #5198) [Link] (16 responses)

It't not version numbers in the traditional sense its a release number. It started with release 4 and now we are at release 8. It's intended to be a reflection of the robustness of the update infrastructure such that one only needs to run "Firefox" and not care about the version, in exactly the same way that people run "Chrome" and don't really care what version they are running as long as it is the latest.

Thunderbird too

Posted Nov 9, 2011 0:12 UTC (Wed) by RCL (guest, #63264) [Link] (8 responses)

Well, we actually do. E.g. NaCl requires at least Chrome 15.

But features of that scale are rare in modern browsers. That is why the perceived ability to get rid of version numbers, because "releases" don't bring a lot more than "twitter searches" and similar stuff that might have been implemented in an addon.

Browser versions will reappear, when

a) major progress restarts in that area and third parties will need to target specific versions, not being able to catch up with pace of development

b) "Firefox"-no-name brand gets old and someone will come up with "Firefox II" (or FireAsaDotzler, or whatever) to "refresh" the franchise.

Actually that's the reason...

Posted Nov 9, 2011 8:17 UTC (Wed) by khim (subscriber, #9252) [Link] (7 responses)

major progress restarts in that area and third parties will need to target specific versions

They need this now - this is exactly why version numbers are incremented regularly.

For example you mentioned NaCl. Well, NaCl was introduced in Chrome 14, but if you need glibc then it's at least Chrome 15, if you want to use in-browser fonts from NaCl then it's Chrome 16 and if you need mouse capture then you are stuck with Chrome 17, etc.

And while changes itself may be small (as you can guess NaCl was much harder to create then mouse capture) psychology matters. If you create something which needs at least Firefox 3.4.5 then you'll hear a lot of complains that your app or website does not work in 3.4.3 with a justification that "it's the same version, it should work", but version 104 vs version 105 are still perceived as "may be different, I need to wait or upgrade".

Actually that's the reason...

Posted Nov 9, 2011 15:32 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (6 responses)

> if you need mouse capture then you are stuck with Chrome 17

Mind linking to the relevant docs on this? I don't want sites grabbing my mouse unless explicitly given permission. If authorization isn't needed, I guess it's one more thing to disable in my webkitgtk builds...

No problem...

Posted Nov 9, 2011 16:09 UTC (Wed) by khim (subscriber, #9252) [Link] (5 responses)

Sorry, I messed up. I meant mouse lock, not mouse capture. Here is the doc.

If I remember correctly you must allow it explicitly every time website asks for it, but Chrome team thinks how to make it less tedious (probably some kind of "sticky acceptance"). A lot of games (both HTML5 and NaCl) want mouse lock, thus I'm not sure it's good idea to disable it (although you may not care about games).

No problem...

Posted Nov 9, 2011 16:32 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (4 responses)

I don't particularly care about games. That pretty much leaves just malicious use of it for me. I'm also unsure of how it would work with a modal browser.

The fancy things that are done in HTML5 aren't that spectacular to me which is why I build my own webkitgtk with most of it disabled. Some things just don't need to happen at all. For example, Engine Yard[1] spikes a CPU after a few focus events on it so that it can waste time and energy animating a silly island or whatever making the site basically useless (though I don't do Ruby at all, if any site I *did* use ended up doing something like that, it's an easy way to get me to search for something else).

[1]http://www.engineyard.com/

It's your choice, of course...

Posted Nov 9, 2011 16:48 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

The fancy things that are done in HTML5 aren't that spectacular to me

Well, HTML5 is mostly about webapps these times and if you don't want and don't need webapps - it's your choice, but then it should not matter to you if someone checks version string or UA of browser, or whatever.

though I don't do Ruby at all, if any site I *did* use ended up doing something like that, it's an easy way to get me to search for something else.

It's your choice. Thankfully few users feel like this so they can usually be ignore. BTW I've checked the Engine Yard: yeah, what it does is completely unnecessary but it does not waste all that many resources and does not waste any when you switch to the other tab so I'm not sure I want to start some kind of jihad which will waste a lot of my own human time and energy to save few percents of battery life on my laptop.

It's your choice, of course...

Posted Nov 9, 2011 17:03 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

> it does not waste all that many resources

Switching focus 4 times incurs a 3 second delay on the whole window (input, clicks, whatever) while the CPU goes to 100% (Core i7@1.8GHz) emptying the event queue (not to mention that the animation doesn't work while the event queue is being processed). More switches seems to be somewhere near quadratic. Luckily I don't do much mousing around, so focus is unlikely to be a trigger (scrolling is usually a heavy hitter when there's a social bar or whatever hanging around).

It's your choice, of course...

Posted Nov 9, 2011 17:07 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

> Switching focus 4 times incurs a 3 second delay

Shouldn't do the such tests while make -j8 is going. It's closer to 4 times is a 1 second delay, but it's still feels quadratic if it falls behind at all.

This is strage: in my case it only needs few seconds to settle...

Posted Nov 9, 2011 17:25 UTC (Wed) by khim (subscriber, #9252) [Link]

Well, yes, it's not the best design you can imagine, but I think the idea that you can fix it in browser is wrong: if it bothers you that much then just don't visit the site. You don't try to fix normal programs with SELinux policies, why do you want to try to do that with webapps?

Thunderbird too

Posted Nov 9, 2011 0:54 UTC (Wed) by clugstj (subscriber, #4020) [Link] (6 responses)

BS. Compatibility matters! Once you've eliminated the version number as an indicator of compatibility, you make everyone else who wants to integrate w/ your software suffer.

Thunderbird too

Posted Nov 9, 2011 3:58 UTC (Wed) by raven667 (guest, #5198) [Link]

Of course compatibility matters but I think browsers are converging on a high level of standards compliance such that, in their opinion, major numbers don't mean much. The standards are also becoming more iterative with small steady changes along with browser development.

It's the same kind of change as when kernel development switched to the 2.6 & 3.x model where there aren't seperate "stable" and "dev" major parallel branches like 2.4/2.5

Thunderbird too

Posted Nov 9, 2011 15:29 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (4 responses)

I disagree. Now that there aren't version numbers, web developers will have to start testing for feature compatability. This is a strictly better solution than blacklisting browsers other than the big 4 just because of a silly UA string.

This is mainly because I use uzbl and get blacklisted from sites despite using the same backend as Safari and Chrome and partially because I compile my own webkit for it, disabling things like audio, video, geolocation, database support, and mouse grabbing when that comes along.

Actually it becomes easier...

Posted Nov 9, 2011 16:32 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

Now that there aren't version numbers, web developers will have to start testing for feature compatability.

Actually it's much easier to check for a single "version number" rather then try to parse large and complex "version string" thus it'll make life of web developers easier, not harder.

because I compile my own webkit for it, disabling things like audio, video, geolocation, database support, and mouse grabbing when that comes along

And this is why I think UA check is the only way to go. It's one thing to support few different browsers with a sane set of features, it's another to use application platform which can have important parts just randomly removed. It's the same thing which plagues desktop linux for ages - no need to have another repeat of the same story. It's one thing to cope with deficiencies of some browsers, but to now cope with randomly crippled ones? No, no need to spend time on that.

Thankfully solution is simple:
1. Check the browser.
2. Check the version number (now when it's just a number it's easy).
3. Refuse to support anything beyond the "big four".
3a. If someone will manage to start your app on unsupported browser - it's his (or her) problem: you can safely close all bugs with "WONTFIX" resolution.

This may be not all that friendly to the DIY guys, but at least this way you'll know that you can safely use local storage, for example (all major browsers support it for many years!) and now worry about fallbacks.

Actually it becomes easier...

Posted Nov 9, 2011 16:55 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

> Actually it's much easier to check for a single "version number" rather then try to parse large and complex "version string" thus it'll make life of web developers easier, not harder.

Wasn't there talk of not sending the version number in UA strings at all?

> And this is why I think UA check is the only way to go. It's one thing to support few different browsers with a sane set of features, it's another to use application platform which can have important parts just randomly removed.

If that's the case, then UA strings need something along the lines of "I'm actually FooBrowser, but you can treat me like Chrome" so that new/other browsers have a *chance* of being recognized in stats. Without this or feature detection, first-party support will be nigh impossible for new/alternate browsers because "no one uses it" when it really just has to masquerade as anything but itself to even work. This is basically vendor lockout and I don't see why it should be accepted here more than anywhere else.

> This may be not all that friendly to the DIY guys, but at least this way you'll know that you can safely use local storage, for example (all major browsers support it for many years!) and now worry about fallbacks.

Good for them. However, until there's support for blacklisting random sites from dropping whatever data they like onto my machine, it gets disabled completely. Sites already have to cope with the chance that cookies don't work and if they encounter that, they put up a page saying "This site needs cookies to do random stuff, unblock us so we can do A, B, and C.", why not do the same with other features?

Actually it becomes easier...

Posted Nov 9, 2011 17:16 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

Wasn't there talk of not sending the version number in UA strings at all?

Who talks about that and where? I've heard some noises from Opera (because it's often forgotten), but so far all browsers report version number.

Without this or feature detection, first-party support will be nigh impossible for new/alternate browsers because "no one uses it" when it really just has to masquerade as anything but itself to even work.

This mechanism is there: at least MS IE allows you to change to useragent string using registry so sites can not just do strncmp on useragent string.

Without this or feature detection, first-party support will be nigh impossible for new/alternate browsers because "no one uses it" when it really just has to masquerade as anything but itself to even work.

Sites do tolerate random additions. So this is not a problem. If someone will decide to follow in Google's footsteps (spend few billions of dollars and get new, supported, browser you can control) it'll not be a showstopper. But if you hope for "equal treatment of minors"... sorry, this phantasy was dispelled long ago. Of course to even be considered seriously you must implement all (or at least most) of the features for the "UA-string donor" browser, or else sites will just blacklist you.

Sites already have to cope with the chance that cookies don't work and if they encounter that, they put up a page saying "This site needs cookies to do random stuff, unblock us so we can do A, B, and C.", why not do the same with other features?

Because cookies were introduced in different era and some of "big four" still gave you a way to disable cookies?

Even so: not all sites bother. Lots of them just break in some way: go in endless redirection loop, or send you to the homepage, etc. I'm sure some sites will check features individually, but most sites will just do what they did for years. It's simple and it works "good enough" so why spend time on some pointless idealistic crusade?

Actually it becomes easier...

Posted Nov 11, 2011 20:56 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Seems I got the UA version disappearing mixed up with the About box hiding of the version number.

For my UA, it seems adding uzbl beside X11 for a Firefox UA still works. Still, I'd like if there were a standard way of doing it for statistical collection purposes.

The impetus behind the video and audio feature disabling is that I don't like websites playing media without consent (e.g., it'd damn near impossible to queue up youtube webpages because they all auto-play). Plus, I have tools to download them and watch them in MPlayer where I get keyboard shortcuts, good seeking, and replay-a-week-later-with-no-download. It also allows me to drop gstreamer dependencies. The database blocking is mostly to hamper tracking and geolocation because I don't need my browser to know.

So yes, I realize that the train has left the station on these features being out there, but it doesn't mean that I'm going to allow sites I visit to control my computer without consent. It's silly that websites can play media without asking "Are you already listening to music? On a call? Listening to an audiobook? Watching another video?" and do nothing if so. If/when uzbl exposes the flags for black/whitelisting these things, I'll enable them again in my builds.

Large version numbers

Posted Nov 9, 2011 0:46 UTC (Wed) by codewiz (subscriber, #63050) [Link] (6 responses)

> I'd just like to know why every release is a major number
> increment. At the rate they are going we are going to be at
> Firefox 39 in 3 years. Why couldn't we stick with the
> major.minor release numbering where only major upgrades got
> a new major number?

Why would a dotted version number like 3.9 constitute an advantage over the plain number 39?

Large version numbers

Posted Nov 9, 2011 3:32 UTC (Wed) by stevenj (guest, #421) [Link] (5 responses)

3.9 and 39 do not merely differ by a decimal point, because 3.9 does not represent a single number.

A minor upgrade to 3.9 is 3.10, whereas going from 39 to 40 makes no such distinction.

The general point is that major.minor.bugfix numbers are triples of numbers, each of which conveys its own technical meaning, not merely arbitrary placements of two decimal points in a single integer.

In analogy to your question, I could ask: Why write dates as year-month-day? Why not simply count days from some arbitrary starting point?

Large version numbers

Posted Nov 9, 2011 3:38 UTC (Wed) by pr1268 (guest, #24648) [Link]

> Why write dates as year-month-day? Why not simply count days from some arbitrary starting point?

Firefox version 2455874.44

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

Large version numbers

Posted Nov 9, 2011 4:32 UTC (Wed) by codewiz (subscriber, #63050) [Link] (3 responses)

> A minor upgrade to 3.9 is 3.10, whereas going from 39 to 40 makes no such distinction.

Just like in the kernel development model, Firefox releases happen every N months. There are no "major" updates, just time-based releases which include whatever features were ready in time for integration.

Most Linux distributions work this way, which is why we have Fedora 16 and RHEL 6. The yy.mm numbering scheme used by Ubuntu and OpenSUSE does not have anything to do with major and minor releases.

> In analogy to your question, I could ask: Why write dates as year-month-day?
> Why not simply count days from some arbitrary starting point?

Indeed, that's an unnecessary complication originated when the motion of celestial bodies was attributed to divine will and incomplete astronomical knowledge. Still, dates expressed in yy-mm-dd format have at least some relationship with actual cycles of our planet. What would a major.minor version scheme mean in the context of Firefox's time-based releases?

Large version numbers

Posted Nov 9, 2011 8:21 UTC (Wed) by ekj (guest, #1524) [Link] (2 responses)

Precisely. A year is *actually* 365.24 days (give or take). And a day is *actually* as long as it is. And a moon-cycle is *actually* as long as it is, allthough that has little practical significance. (and doesn't match the "month" anyway)

But sure, we could use year day.fraction and do away with months, weeks, hours, minutes and seconds.

2011 150.5 would be mid-day on the 150th day of year 2011.

Large version numbers

Posted Nov 9, 2011 12:47 UTC (Wed) by robbe (guest, #16131) [Link] (1 responses)

Multi-part dates (or version numbers, to give some semblance of being on-topic) seem to be easier to parse than unstructured ones.

Quick: if I invite you to an outdoors event on 2012 day 222, will you need to bring your jacket? I guess we could start to remember key day numbers (e.g. "frost recedes around 74", "324 is our anniversary"), but I think we more easily remember day-month combinations than three-digit numbers.

The days-since-the-epoch scheme is insane.

Large version numbers

Posted Nov 9, 2011 12:59 UTC (Wed) by ekj (guest, #1524) [Link]

I dunno about that. you can skip the last digit in the year if you care only about season, you're thus left with 36 10-day periods, I guess that granularity is a little high, but I don't think it's a *lot* harder.

Do you need a jacket for an event at 22/36 of a year isn't much harder than Do you need a jacket for an event at 8/12 of a year which is the current system.

Multi-part version-number can confuse too; I've seen several people be confused about what is better: 2.27 and 2.3 if you read them as decimals, you'll end up thinking that 2.3 is the higher number thus the newest version.

Thunderbird too

Posted Nov 9, 2011 8:27 UTC (Wed) by Karellen (subscriber, #67644) [Link]

Because the devs decided they couldn't be bothered with backwards compatibility between versions any more. They want to be free to break source compatibility, binary compatibility and add-on compatibility every six weeks (not just for Firefox, but also for the underlying libs they control, including libxul/xulrunner), hence a new major version number each time.

High version numbers

Posted Nov 9, 2011 9:00 UTC (Wed) by mjthayer (guest, #39183) [Link] (2 responses)

$ udevadm version
173
Even Firefox will take a while to catch up with udev.

High version numbers

Posted Nov 9, 2011 12:35 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

And even longer to catch up with less:

$ less --version
less 444

High version numbers

Posted Nov 9, 2011 14:09 UTC (Wed) by SimonKagstrom (guest, #49801) [Link]

less version is more.

Thunderbird too

Posted Nov 9, 2011 11:10 UTC (Wed) by slashdot (guest, #22014) [Link]

Well, Firefox 39 isn't very interesting, but as we all know Firefox 42 will be the answer to the ultimate question of life, the universe, and everything.

Firefox's version numbering has been designed specifically to reach that milestone as soon as possible, for the benefit of mankind.

A further revision of the process is also being studied to be able to reach Firefox 31337 in our lifetime, as that's clearly most elite.

Thunderbird too

Posted Nov 9, 2011 17:22 UTC (Wed) by drago01 (subscriber, #50715) [Link]

Does this really matter? It is just a meaningless number ... seems like this discussion will always restart after a firefox release ;)

Thunderbird too

Posted Nov 10, 2011 23:49 UTC (Thu) by kripkenstein (guest, #43281) [Link] (4 responses)

> I'd just like to know why every release is a major number increment. At the rate they are going we are going to be at Firefox 39 in 3 years. Why couldn't we stick with the major.minor release numbering where only major upgrades got a new major number?

Firefox and Chrome both bump the major version number every 6 weeks, because they *do* include changes in those 6-week updates that break earlier stuff. Not bumping the major version number would be potentially misleading, since people assume minor version numbers do not introduce incompatibilities.

Firefox also had the reason that Chrome already used that numbering scheme, so it makes sense to standardize on one that is familiar to people already.

Side note: I'm surprised by the comments here on LWN. I expect Slashdotters to say "Mozilla and Google are just trying to get high version numbers, it's all marketing, blah blah", but here? I expect more from LWN readers! ;)

Thunderbird too

Posted Nov 11, 2011 15:36 UTC (Fri) by nix (subscriber, #2304) [Link] (3 responses)

However, Chrome has a proper extensions API, so version number changes almost never break extensions.

Thunderbird too

Posted Nov 11, 2011 22:15 UTC (Fri) by kripkenstein (guest, #43281) [Link]

Yes, Chrome's extension API is simpler and less susceptible to breakage when there is an update. (Firefox has jetpack addons which are similar, but they aren't used much yet.)

But websites can and do break with Chrome and Firefox updates. There is no way around that. So to not use a major version number would be misleading.

Thunderbird too

Posted Nov 12, 2011 15:35 UTC (Sat) by gerv (guest, #3376) [Link] (1 responses)

The downside of which, of course, is that extensions can't do nearly as much in Chrome as they can in Firefox. They can only do what the Chrome developers allowed for in their API.

Gerv

Thunderbird too

Posted Nov 12, 2011 16:56 UTC (Sat) by nix (subscriber, #2304) [Link]

One simple extension that always works is worth a hundred cool ones that can break at any time because of an update including security fixes that you *have* to do. Maybe I am showing myself to not be a cool cat by valuing stability and security above whizbang, but so be it.

Firefox 8 released

Posted Nov 8, 2011 21:39 UTC (Tue) by linuxjacques (subscriber, #45768) [Link] (10 responses)

And it still only shows me the 32-bit version.

Firefox 8 released

Posted Nov 9, 2011 12:34 UTC (Wed) by RobSeace (subscriber, #4435) [Link] (9 responses)

Yeah, the x86_64 version is there, but you still have to go hunting to find it... You'd think they could at least offer it if they detect you're already running a 64-bit version...

Firefox 8 released

Posted Nov 10, 2011 23:55 UTC (Thu) by kripkenstein (guest, #43281) [Link] (8 responses)

> Yeah, the x86_64 version is there, but you still have to go hunting to find it... You'd think they could at least offer it if they detect you're already running a 64-bit version...

I believe we (I work at Mozilla) don't promote 64-bit builds because we aren't confident they are fully up to par yet. There are various bugs on those that don't exist in 32-bit builds.

But if you're a power user (and if you're reading this here, you are ;) then have fun with the 64-bit builds. Expect possible breakage though.

Firefox 8 released

Posted Nov 11, 2011 14:38 UTC (Fri) by RobSeace (subscriber, #4435) [Link] (7 responses)

That's funny, because the reason I finally broke down and tried a 64-bit build (of 7.0.1) is because the 32-bit build kept crashing repeatedly for me, and I just got sick of it... For a while, I went back to 5, which was the last one that was rock-solid for me, but eventually when I saw Adobe was now officially supporting the 64-bit Flash plugin, I decided to give 64-bit Firefox a try... And, you know what? It's damn near rock-solid again! I think I had maybe 1 crash total with 7.0.1 64-bit in all the time I used it, and so far have had none with 8.0 64-bit... So, I think you guys have things a bit backwards: it's your 32-bit builds that could really use stabilizing and improvement, while your 64-bit builds are far superior!

(I'm on CentOS 5, so the cause is probably some ancient lib version or something... But, all I know is the 64-bit build seems to work great, so I'm sticking with it...)

Still, even if you're not promoting it, I'd think you could detect we were already running a 64-bit version, which means we obviously want to continue doing so, and offer up the new 64-bit version for download instead of the 32-bit one... I'm not saying offer it to someone currently running a 32-bit version... *shrug*

Firefox 8 released

Posted Nov 11, 2011 18:11 UTC (Fri) by dlang (guest, #313) [Link]

I've been using the 64 bit builds of firefox for years and it's been a _long_ time since I've had a crash (OOM problems prior to FF 7 yes, crashes no)

but the point of only offering 32 bit builds, even if I am already running a 64 bit build (and so have 64 bit extensions loaded that will break if I install the 32 bit build) is not a good thing

Firefox 8 released

Posted Nov 11, 2011 22:17 UTC (Fri) by kripkenstein (guest, #43281) [Link] (5 responses)

> Still, even if you're not promoting it, I'd think you could detect we were already running a 64-bit version, which means we obviously want to continue doing so, and offer up the new 64-bit version for download instead of the 32-bit one... I'm not saying offer it to someone currently running a 32-bit version... *shrug*

Ah, interesting point. Are you talking about automatic updates through the browser itself, or what you are offered on the website, or both?

Firefox 8 released

Posted Nov 11, 2011 22:30 UTC (Fri) by RobSeace (subscriber, #4435) [Link] (4 responses)

I mean on the main website, where it offers the newest version via the big green button... It always just offers the 32-bit one, it seems, even if I go there with a 64-bit version... It detects I'm running Linux, presumably via User-Agent, so I'd think it could detect I'm running a 64-bit version already, too... (I turned off auto-updates, so I'm not sure what it does there if running the 64-bit version...)

Firefox 8 released

Posted Nov 11, 2011 23:38 UTC (Fri) by dlang (guest, #313) [Link]

and especially when looking at a beta build

I actually got frustrated enough a couple of versions ago to use the ubuntu PPA and live with it updating every couple of nights because it was just too painful to track down the 64 bit build otherwise.

Firefox 8 released

Posted Nov 12, 2011 18:09 UTC (Sat) by kripkenstein (guest, #43281) [Link] (2 responses)

I could be wrong, but I believe the user agent doesn't say that you are on a 64-bit browser (it does say the OS, but not the browser build itself). So I'm not sure this is possible.

Firefox 8 released

Posted Nov 12, 2011 18:39 UTC (Sat) by RobSeace (subscriber, #4435) [Link] (1 responses)

It does distinguish... From my current 8.0 64-bit:

Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0

And, from 32-bit 7.0 (the newest 32-bit build I've got lying around):

Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0) Gecko/20100101 Firefox/7.0

Firefox 8 released

Posted Nov 12, 2011 18:51 UTC (Sat) by kripkenstein (guest, #43281) [Link]

Ah, interesting!

Ok, I filed a bug,

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

I think it's a very good idea to do this, thanks for the suggestion :)

Still crash unattended?

Posted Nov 8, 2011 22:19 UTC (Tue) by ncm (guest, #165) [Link] (6 responses)

The most salient feature of 7 is that it only crashes when I haven't used it for a couple of days. Every Monday, I restart it, and it runs through Friday without hiccups, and then crashes over the weekend when I'm not here. I guess I could think of it as GC that actually works; this way its RSS rarely goes much over 2G. If it would only put its windows back on the right desktops on a restore, I would count that as success.

Still crash unattended?

Posted Nov 8, 2011 22:42 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

I'm now running the 9 alpha, but I ran the 7 beta for several weeks before migrating and didn't have any crashing problems. before that (on 6) I was having firefox killed by the OOM killer on a frequent basis, check that you aren't having a problem along those lines.

Still crash unattended?

Posted Nov 9, 2011 3:15 UTC (Wed) by set (guest, #4788) [Link]

Firefox was getting killed by the OOM killer for me at random intervals ranging from days to weeks of uptime. I upgraded to version 6 and it seemed to get worse. I ended up moving my ~/.mozilla directory aside, starting fresh and the memory gobbling stopped. Then I migrated the custom settings I had made under ~/.mozilla that I still understood, and it has remained stable ever since. I cannot even guess how many years and incarnations of mozilla browsers had been using that, or what could possibly have been causing the problem, but I am back to my normal usage; 12-20 tabs open running continuously.

Still crash unattended?

Posted Nov 9, 2011 6:13 UTC (Wed) by ncm (guest, #165) [Link]

I believe OOM sends a SIGKILL, while firefox is getting SIGSEGV. But I'll try set's suggestion; .mozilla on this box goes back (only!) five years. Firefox is running under gdb this week, so on Monday we'll know more -- unless gdb crashes first.

Firefox stability

Posted Nov 9, 2011 10:48 UTC (Wed) by Cato (guest, #7643) [Link]

I used to have very frequent crashes on Linux, and a bug where the IFRAME popped out into a window - https://bugzilla.mozilla.org/show_bug.cgi?id=263160 - which made it almost unusable on Linux.

These issues went away some time ago and Firefox now seems as stable on Linux as it is on Windows. I like that the latest Firefox still works on older Linux distros (Ubuntu 8.04), as does Opera - Chrome says 'your OS is unsupported' and refuses to upgrade itself.

I did find that Firefox 8 doesn't properly reload tabs when the new 'only load tabs when selected' feature is turned on (using Windows) so that seems a bit buggy still.

Still crash unattended?

Posted Nov 9, 2011 14:54 UTC (Wed) by tpo (subscriber, #25713) [Link] (1 responses)

It's god's way of telling you to switch off the computer when you're not using it, instead of letting the software burn joules during gratuitous self reflection.

Still crash unattended?

Posted Nov 9, 2011 16:16 UTC (Wed) by bronson (subscriber, #4806) [Link]

Yeah, then you can burn joules doing gratuitous full fscks every month. :)

Firefox 8 released

Posted Nov 9, 2011 1:58 UTC (Wed) by akumria (guest, #7773) [Link] (17 responses)

The headline feature appears (sadly) to be a Twitter search option.

It appears the grumpy editor has turned into the sarcastic editor.

The headline feature, i.e. the one they promote the most is:

Add-ons installed by third party programs are now disabled by default

Whilst that is uncommon on Linux platforms (except for Ubuntu) it is reasonably common on Windows that someone you know has downloaded an anti-virus program and it now feels it should take over the search bar, etc.

Headline feature

Posted Nov 9, 2011 2:17 UTC (Wed) by corbet (editor, #1) [Link] (1 responses)

The first thing mentioned in the blog entry - the only "above the fold" item - is the twitter search feature. I don't think it's overly sarcastic to point that out.

Headline feature

Posted Nov 9, 2011 11:28 UTC (Wed) by akumria (guest, #7773) [Link]

Ah, right, the blog post. I was looking at the release notes.

Odd how they have different headline features in each.

Firefox 8 released

Posted Nov 9, 2011 7:46 UTC (Wed) by taavi (guest, #28277) [Link] (2 responses)

For me the headline feature is "load tabs on demand". Startup with some app tabs and tabs from previous session, is much more quicker.

Firefox 8 released

Posted Nov 9, 2011 10:50 UTC (Wed) by Cato (guest, #7643) [Link]

Use with care, I had to disable this on Windows as after a few restarts the tabs would not load even when selected. A shame as Firefox restarts were so fast with this enabled.

For easy restarts, I recommend the Restartless Restart addon that just adds a Restart option to the main (File) menu. And doesn't require a restart to install ...

Tabs loaded on demand

Posted Nov 9, 2011 12:34 UTC (Wed) by robbe (guest, #16131) [Link]

Also good for tor users, I guess.

Firefox 8 released

Posted Nov 9, 2011 8:30 UTC (Wed) by job (guest, #670) [Link] (11 responses)

What does that even mean, "disabled by default"? Do plug-ins (sorry, "add-ons") need to be remotely enabled with some cryptographic signature for Firefox to run them? (I just hope it just doesn't mean "installation of addons is now more complicated".)

Firefox 8 released

Posted Nov 9, 2011 9:07 UTC (Wed) by ekj (guest, #1524) [Link] (9 responses)

It's been a problem that unrelated third-party programs being installed on the same computer, take the liberty of inserting add-ons into firefox, bypassing the normal restrictions. (only add-ons from user-approved sites are installed, and the user needs to explicitly click "Install" after having watched a dialogue warning about the dangers of untrusted addons for atleast 5 seconds)

For example, if you install a certain instant-messaging-crapware-program, you also get, at no extra charge, a firefox-addon that'll change your default search-provider to Yahoo, and set your homepage to a banner-ad-infested hell. (and it'll reset these two settings on every firefox launch)

Such addons --- i.e. ones that are not installed trough firefox, but merely present in the apropriate addon-directory, will now be disabled by default. (though you can still enable them in the addon-manager if you *do* want them)

Firefox 8 released

Posted Nov 9, 2011 10:52 UTC (Wed) by Cato (guest, #7643) [Link] (3 responses)

On Windows, Microsoft Office, Adobe Reader and quite a few other applications do this, and often they re-enable the addons/plugins every time the application is updated. Great that Firefox now addresses this.

Firefox 8 released

Posted Nov 9, 2011 13:02 UTC (Wed) by gidoca (subscriber, #62438) [Link] (2 responses)

Yes, it is. I wonder though how long it will take for application developers to figure out how to bypass this.

Firefox 8 released

Posted Nov 9, 2011 13:11 UTC (Wed) by Cato (guest, #7643) [Link] (1 responses)

Firefox is just scanning for installed addons when it starts up, I believe, so the addon would have to change Firefox's own files to fool it - probably possible but addons that do that are really crossing the line into malware and should be treated as such.

Firefox 8 released

Posted Nov 9, 2011 20:43 UTC (Wed) by gidoca (subscriber, #62438) [Link]

IMHO, changing the home page and default search provider at every start of Firefox is already well beyond the line to malware.

Firefox 8 released

Posted Nov 10, 2011 9:23 UTC (Thu) by job (guest, #670) [Link] (4 responses)

You just said "disabled by default" with many more words. The question remains what Mozilla can do to remedy this?

The only thing I can think of is to make installation really convoluted, perhaps require that several different changes are made, in sync, to undocumented file formats. A reasonably intelligent person would recognize this as a solution probably worse than the problem.

I'm slightly sad that not only is the release announcement made of these nonsensical PR bullet points, but they are repeated on news sites and blogs while no one understands what they mean. People do not seem to expect anything else anymore. Web browser development has been made more ivory tower-ish over the past few years and all that's visible on the outside is new window dressing every few months.

Solution is simple...

Posted Nov 10, 2011 9:48 UTC (Thu) by khim (subscriber, #9252) [Link] (3 responses)

The only thing I can think of is to make installation really convoluted, perhaps require that several different changes are made, in sync, to undocumented file formats.

Not really. You only need one such file - and you already have it: browser binary. Just sign the preferences file with some key unique to the browser build - and that's it. You will need to include keys for all previous officially released builds, obviously (to make it possible to upgrade), but this is not a big deal.

Sure, crapware developers may try to scan you binary to find embedded keys, but these schemes will be inherently fragile. Your goal is not to make something impossible but merely make something unfeasible, after all.

Solution is simple...

Posted Nov 10, 2011 17:03 UTC (Thu) by job (guest, #670) [Link] (2 responses)

I'd like to challenge that. Even if keys were unique for each build they are stored somewhere and a third party installer could just as easily extract them. You would need to obfuscate keys by hand at random positions for each release for this scheme to slow down a third party installer noticeably.

It amounts to a pretty standard copy protection scheme, and all of those are broken not very long after release. (By people who receive by pay by the way, defeating this installer would be worth money.)

This is not so simple.

Posted Nov 10, 2011 17:42 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

You would need to obfuscate keys by hand at random positions for each release for this scheme to slow down a third party installer noticeably.

Nope. We are talking crapware here, not malware. You only need to slow down it enough to trigger § 1201. After that point you don't have an example of crapware. It's clearly illegal malware and should be treated as such: it will be added to virus databases, etc.

This is not so simple.

Posted Nov 14, 2011 20:28 UTC (Mon) by job (guest, #670) [Link]

I see. I would never have thought that I would find EUCD/DMCA on my side some day, but what do you know...

Firefox 8 released

Posted Nov 10, 2011 10:13 UTC (Thu) by Cato (guest, #7643) [Link]

Plugins (binary code) are still separate from extensions (XUL code) in Firefox btw. The collective term is add-ons.

Search and ad funding for open source

Posted Nov 9, 2011 11:00 UTC (Wed) by Cato (guest, #7643) [Link] (3 responses)

I was thinking how lucky we all are to have a great open source browser like Firefox that's not dependent on a mega corporation, and has the funding to cover full-time developers, huge download traffic, etc.

Since there was a discussion about Linux Mint using a Mozilla-like search and ads funding model, and this model seems to work well for both projects - maybe more open source projects should adopt this model? I don't mind unblocking ads for Mint since it is doing good work on a usable distro, and search based revenue is even less hassle. It does open up a small risk of malvertising but that's not such an issue for Linux users.

One of the key things I hate, which Mint has so far avoided, is banner ads that move, blink, etc - I can live with even banner ads if they are static and reasonably relevant, but motion in the corner of my eye is far too distracting. Unfortunately, that's why I still have to disable LWN ads.

Unlike many of the other revenue models (open core, dual licensing, selling support contracts), the ad model is easily adopted by almost any project that gets some web traffic, and the search model is applicable to Linux distros as well as browsers.

Maybe an LWN article on the pros and cons of this revenue model would be worth while?

Search and ad funding for open source

Posted Nov 9, 2011 13:37 UTC (Wed) by njwhite (guest, #51848) [Link] (2 responses)

I for one really hate adverts. I'd *far* rather (and do) donate to projects which are important to me, rather than have them bombard me with crap to encourage me to consume more. Ads are never truly relevant; they're paid placements on what you actually want to read.

I expect it is true that most people don't donate to projects they rely on, or really think of doing so, but changing that mindset makes projects much more sustainable, and our mental environment much nicer.

I doubt it'll work

Posted Nov 9, 2011 14:36 UTC (Wed) by khim (subscriber, #9252) [Link]

LWN is barely able to collect enough fees to support itself - and people are accustomed to pay for magazines IRL.

I'm not sure if it'll be possible support major project like Mozilla this way.

Search and ad funding for open source

Posted Nov 9, 2011 17:09 UTC (Wed) by Cato (guest, #7643) [Link]

I should have mentioned donations (quite a lot of Mint funding comes from them), but as long as ads are easily blockable with Adblock Plus, you can donate instead. Search-based funding doesn't involve graphical ads and the project gets the revenue even if you block the text ads, which I find are quite relevant and sometimes useful.

Awful image quality in image scaling

Posted Nov 9, 2011 12:10 UTC (Wed) by patrick_g (subscriber, #44470) [Link]

New versions after new versions....and still no fix for this bug introduced in FF 3.0 years ago. It's really sad.
The difference in image quality between Chrome and Firefox is stunning. Look at "The annotated Alice" cover in this screenshot.

Firefox 8 released

Posted Nov 10, 2011 18:25 UTC (Thu) by dps (guest, #5725) [Link]

I am running firefox 8 on Mac OS X and can't see any obvious twitter search feature, which is a good thing IMHO. I don't use twitter or facebook myself, although I know some people do. Maybe the young value not having any privacy whatsoever.

All the social media sites I have seen ask for far too much personal information which is none of their business... I think the best way of keeping this information private is not putting in the could in the first place.