Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Turning off win64 builds

7,677 views
Skip to first unread message

Benjamin Smedberg

unread,
Nov 16, 2012, 1:11:56 PM11/16/12
to dev-apps-firefox List, mozilla.dev.planning group
The Windows 64-bit builds are a constant source of misunderstanding and
frustration, at least in the following ways:

* Many plugins are not available in 64-bit versions
* The plugins that are available don't work correctly in Firefox because
we haven't implemented things like windowproc hooking, which means that
hangs are more common
* Crashes submitted by 64-bit users are currently not high priority
because we are working on other things.
** This is frustrating for users because they feel (and are!) second-class.
** It is also frustrating for stability team triage because crash-stats
does not easily distinguish between 32-bit and 64-bit builds in the
topcrash lists and other reports. We basically ignore a set of nightly
"topcrashes" because they are 64-bit only. (See bug 811051).

For these reasons, I would like to propose that we disable the 64-bit
Windows nightly builds. We should publish a custom update to move
current win64 nightly users back onto win32.

I also think we should consider disabling the win64 builders completely,
but I'm also willing to shelve that proposal for another time if it is
controversial. If we *don't* disable win64 hourlies, I plan on adding
--disable-plugins to their configuration.

--BDS

Please followup to mozilla.dev.apps.firefox

sta...@gmail.com

unread,
Nov 18, 2012, 8:50:28 PM11/18/12
to dev-apps-firefox List, mozilla.dev.planning group
How about you get with the times and fix them up to be first class instead. The installer should be capable of detecting the system it's run on and install the correct version. All major browser plugins are available on 64bit now and the ones that are not are the source of topcrashes anyway. Like shitty skype or avg/norton/whatever plugins.

Benjamin Smedberg

unread,
Nov 21, 2012, 11:19:21 AM11/21/12
to dev-apps-firefox List, mozilla.dev.planning group
On 11/16/2012 1:11 PM, Benjamin Smedberg wrote:
>
> For these reasons, I would like to propose that we disable the 64-bit
> Windows nightly builds. We should publish a custom update to move
> current win64 nightly users back onto win32.
Thank you to everyone who participated in this thread. Given the
existing information, I have decided to proceed with disabling windows
64-bit nightly and hourly builds. Please let us consider this discussion
closed unless there is critical new information which needs to be presented.

--BDS

stone...@gmail.com

unread,
Nov 22, 2012, 12:54:57 AM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group
My current Firefox state doesn't come anywhere near fitting in two gig.

I've been using Firefox since it was still called Mozilla.

This will drive me away.

Don't be a neckbeard and take my tools away just because you can't get them up to spec. I'd rather live with broken Firefox than be screwed into an unacceptable memory map.

Yes. Leave it out there, crashing four times a day.

pika...@gmail.com

unread,
Nov 22, 2012, 3:13:42 AM11/22/12
to dev-apps-firefox List
Although I always stick to the i386 builds, and non-Windows OS, I'm still hope there always be choices to use x64 version of Firefox.

Please just make it better or avoid its problems better but not just shutdown it.

Michal Suchanek

unread,
Nov 22, 2012, 5:49:34 AM11/22/12
to
Hello,
For me the nightlies were very stable, at least compared to the 32bit
builds.

I tried a few plugins and they worked but I normally disable most
plugin content with noscript anyway.

Windows is not my primary platform. While using it for a while I found
that the default 32bit builds are just not going to cut it.

If there are remaining 64bit specific problems those should be perhaps
addressed in pre-release notes or something since it has not been
released yet and can't have release notes then ;-)

I did not encounter any of them, however.

I think 64bit builds are required for Firefox to have some future.

Thanks

Michal

mp3...@gmail.com

unread,
Nov 22, 2012, 6:41:48 AM11/22/12
to
I would prefer the 64bit builds be left alone.. not all of us use weird plugins etc. 64bit flash and java work bbrilliantly in windows and 64bit Firefox. Infact stable enough to run nightlies on my work PC, as my primary browser!

Please let's not drive people away unnecessary.

Paul [sabret00the]

unread,
Nov 22, 2012, 7:47:49 AM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group
Personally, I don't think this is a very forward thinking decision. Win 32 usage is in decline as users move towards more modern systems. Some of those users are moving away from desktop all together, but 64 bit will be a big winner. The reasons above are good. But at the very least, a discussion should've been had. Or at least their should have been some pretence as to a discussion taking place, rather than "I wanna do this" => "I'm gonna do this". This isn't the open discussion format that makes so many of us so proud about Mozilla and Firefox and that's disappointing. Especially considering one of the 'other projects' that's draining resources that could go to this, was bought about in the same closed discussion manner.

Paul [sabret00the]

unread,
Nov 22, 2012, 7:47:49 AM11/22/12
to mozilla.de...@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List
On Wednesday, 21 November 2012 16:19:44 UTC, Benjamin Smedberg wrote:

satfg...@gmail.com

unread,
Nov 22, 2012, 8:21:01 AM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group
Just wow... You really hate people using your software that much? Why bother at all?

I didn't want to, but off to Chrome we go! Real shame, very disappointed.

WaltS

unread,
Nov 22, 2012, 8:41:01 AM11/22/12
to
On 11/22/2012 08:21 AM, satfg...@gmail.com wrote:
> Just wow... You really hate people using your software that much? Why bother at all?
>
> I didn't want to, but off to Chrome we go! Real shame, very disappointed.
>

Ah, you know Chrome is only 32-bit.

When did the win64 build ever make it up the chain from Nightly > Aurora
> Beta > Release? AFAIK it has always only been an unstable Nightly,
for testing purposes only. I sure wouldn't want to use it for my
financial institutions.

You want to use 64-bit versions of Firefox, switch to Mac or Linux.

--
Fedora 17 (64-bit) KDE 4.9.2
Thunderbird Release
Why are you punishing me for ignoring the rules?

Armen Zambrano G.

unread,
Nov 22, 2012, 9:03:31 AM11/22/12
to
In case anyone want to look into what has been discussed in the past
please go ahead and read the following topics:
"Windows 64-bit Firefox - Product Recommendations" [1] - March 12, 2012

From Product's perspective we were recommended in March to maintain the
experimental nightly builds.

I would nevertheless recommend giving them a prompt telling them that
Windows 32-bit is maintained at this point and that they can migrate to
Windows 32-bit.

I would ask to move Win64 users on other branches to mozilla-central's.

[1]
https://groups.google.com/d/topic/mozilla.dev.planning/HMg_Cef17-M/discussion

to...@methodcity.com

unread,
Nov 22, 2012, 9:58:39 AM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group
I agree; get with the times and fix them!

herma...@gmail.com

unread,
Nov 22, 2012, 12:11:44 PM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group
Yep, i guess waste time programing for window$. R.I.P.

MB

unread,
Nov 22, 2012, 2:52:02 PM11/22/12
to
On Thursday, 22 November 2012 05:41:02 UTC-8, WaltS wrote:
>
> Ah, you know Chrome is only 32-bit.
>

A near unlimited amount of 32-bit processes each with their own address space vs Firefox trying to stuff everything into the same address space.

Please don't be silly.

MB

claud...@gmail.com

unread,
Nov 22, 2012, 3:24:07 PM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group
While i believe the the points (and priorities) are sound, i am one of those people running ffx nightly x64 as primary browser. mainly because it works far better than the i386 build. How is a 32bit version supposed to handle 6gb ffx sessions? will this drive me a away? no, but only because no other browser handles 1000+ tabs... wait now firefox doesn't anymore! guess it's time for browser re-evaluations...

hey it would be quite interesting to know what's changed since march... back then the consensus was to keep them running since x64 is the future...

just glad that at least at home i'm safely runnning osx... (thats definitely not the case at work)

Gregory Szorc

unread,
Nov 22, 2012, 4:00:57 PM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group, Benjamin Smedberg
On 11/21/12 8:19 AM, Benjamin Smedberg wrote:
> On 11/16/2012 1:11 PM, Benjamin Smedberg wrote:
>>
>> For these reasons, I would like to propose that we disable the 64-bit
>> Windows nightly builds. We should publish a custom update to move
>> current win64 nightly users back onto win32.
> Thank you to everyone who participated in this thread. Given the
> existing information, I have decided to proceed with disabling windows
> 64-bit nightly and hourly builds. Please let us consider this discussion
> closed unless there is critical new information which needs to be
> presented.

For those running into the 32 bit memory ceiling, you have a legitimate
complaint: your usage pattern of Firefox may no longer be supported by
32 bit builds. I don't like it when someone forces me to change either,
so I sympathize with you.

Many of the people hitting this memory ceiling are hitting it because
they have many tabs open - possibly hundreds of tabs. There are a number
of things that can be done to abate this.

The obvious solution: don't have so many tabs open! May I suggest using
some form of bookmarking or read it later instead. There are numerous
add-ons available if the features in Firefox itself aren't satisfactory.

Another solution is to restart your browser periodically. Firefox 13
introduced on-demand tab loading. So, when you restart your browser,
tabs aren't loaded until you actually use them. The relevant preference
in about:config is browser.sessionstore.restore_on_demand. It's "true"
by default. Be sure you haven't accidentally changed it to false.

These are two things tab-heavy users can do today to control memory
usage. Unfortunately, they both require a change in browsing behavior.
This is not ideal.

In bug 675539 (https://bugzilla.mozilla.org/show_bug.cgi?id=675539), we
are tracking a feature to automatically unload unused tabs, freeing
memory in the process. Once this lands, this should (finally) keep the
memory footprint of Firefox in check for tab-heavy users.

Now, not all encounters with the memory ceiling are due to large numbers
of tabs. Generally speaking, if you get Firefox to use 1GB+ of memory
with only 3 or 4 tabs open, you are dealing with a) something suboptimal
in Firefox itself b) a leaky or wasteful add-on or plugin c) a
sub-optimally designed web site d) a web site that truly needs massive
amounts of resources. Arguably the only scenario that's OK there is "d."
And, these web sites are currently few and far between. As they become
more prevalent, I'm sure Mozilla will revisit the 64 bit decision and/or
a per-process browser model because not doing so would be to the
detriment of the web.

Anyway, if you encounter extreme memory usage with only a few open tabs,
please file a bug at https://bugzilla.mozilla.org/. By doing so, you are
telling the people who have the greatest chance of fixing it.

Gregory

Nicholas Nethercote

unread,
Nov 22, 2012, 5:24:08 PM11/22/12
to Armen Zambrano G., dev-pl...@lists.mozilla.org
On Fri, Nov 23, 2012 at 1:03 AM, Armen Zambrano G. <arm...@mozilla.com> wrote:
> In case anyone want to look into what has been discussed in the past please
> go ahead and read the following topics:
> "Windows 64-bit Firefox - Product Recommendations" [1] - March 12, 2012
>
> From Product's perspective we were recommended in March to maintain the
> experimental nightly builds.

And now bsmedberg has unilaterally overridden this well-discussed
decision. Plenty of users are clearly upset, and I'm surprised that
no Mozilla developers (except possibly Armen) have objected...

Nick

Tom Schuster

unread,
Nov 22, 2012, 6:53:13 PM11/22/12
to Nicholas Nethercote, mozilla. dev. planning group, Armen Zambrano G.
Sorry, but I also see no response here that would legitimate this desicion.
5 days to remove a platform is kind of short. I am not even saying we
should support win64 right now, but stuff is going to break. (From my
experience on the JS team, win64 can be nasty). And from what I hear Chrome
is working on x64.
Could we get feedback from a few more mozilla people?
The media response as usual...

Cheers,
Tom
On Nov 22, 2012 11:24 PM, "Nicholas Nethercote" <n.neth...@gmail.com>
wrote:

> On Fri, Nov 23, 2012 at 1:03 AM, Armen Zambrano G. <arm...@mozilla.com>
> wrote:
> > In case anyone want to look into what has been discussed in the past
> please
> > go ahead and read the following topics:
> > "Windows 64-bit Firefox - Product Recommendations" [1] - March 12, 2012
> >
> > From Product's perspective we were recommended in March to maintain the
> > experimental nightly builds.
>
> And now bsmedberg has unilaterally overridden this well-discussed
> decision. Plenty of users are clearly upset, and I'm surprised that
> no Mozilla developers (except possibly Armen) have objected...
>
> Nick
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

PhillipJones

unread,
Nov 22, 2012, 7:00:19 PM11/22/12
to
Gregory Szorc wrote:
> On 11/21/12 8:19 AM, Benjamin Smedberg wrote:
>> On 11/16/2012 1:11 PM, Benjamin Smedberg wrote:
>>>
>>> For these reasons, I would like to propose that we disable the 64-bit
>>> Windows nightly builds. We should publish a custom update to move
>>> current win64 nightly users back onto win32.
>> Thank you to everyone who participated in this thread. Given the
>> existing information, I have decided to proceed with disabling windows
>> 64-bit nightly and hourly builds. Please let us consider this discussion
>> closed unless there is critical new information which needs to be
>> presented.
>
> For those running into the 32 bit memory ceiling, you have a legitimate
> complaint: your usage pattern of Firefox may no longer be supported by
> 32 bit builds. I don't like it when someone forces me to change either,
> so I sympathize with you.
>
> Many of the people hitting this memory ceiling are hitting it because
> they have many tabs open - possibly hundreds of tabs. There are a number
> of things that can be done to abate this.
>
> The obvious solution: don't have so many tabs open! May I suggest using
> some form of bookmarking or read it later instead. There are numerous
> add-ons available if the features in Firefox itself aren't satisfactory.

Or don't use tabs at all.
--
Phillip M. Jones, C.E.T. "If it's Fixed, Don't Break it"
http://www.phillipmjones.net mailto:pjon...@comcast.net

dcl...@gmail.com

unread,
Nov 23, 2012, 3:48:05 AM11/23/12
to dev-apps-firefox List, mozilla.dev.planning group
At home I use Debian Linux 64bits, with iceweasel 64bits. At work I use firefox (nightly) 64 bits. Now as with Debian, It's time to change web browser. It's time because AGAIN you force me to stop using your browser.

Bye Bye Mozilla!!

david....@gmail.com

unread,
Nov 23, 2012, 3:57:44 AM11/23/12
to dcl...@gmail.com, dev-pl...@lists.mozilla.org, dev-apps-firefox List
Mozilla is taking it too far now about this as I am cced in a bug were a lot of people want the 64 bit

If mozilla stops doing 64 bit then mozilla will loose interest with people and this will be made official what mozilla does not want to cater for all of its users

I for one would like to see mozilla on stable for 64 bit and also beta


Sent from my BlackBerry® wireless device

jari....@mezzoforte.fi

unread,
Nov 23, 2012, 4:27:19 AM11/23/12
to dev-apps-firefox List, mozilla.dev.planning group
On Friday, November 16, 2012 8:12:14 PM UTC+2, Benjamin Smedberg wrote:
> The Windows 64-bit builds are a constant source of misunderstanding and
> frustration, at least in the following ways:
> * Many plugins are not available in 64-bit versions
> * The plugins that are available don't work correctly in Firefox because

This is complete BS!
I've been running waterfox pretty much since they started. I am a web developer and require Flash and Java plugins. They work perfectly.
Your point of view is the 1% of users that are having issues with weird plugins. 99% 64-bit users are happy anyway.

Btw. Thanks waterfox guys! Looks like I'll be sticking with you for a very long time.

Regards,
Jari Turkia

rubi...@gmail.com

unread,
Nov 23, 2012, 5:22:40 AM11/23/12
to dev-apps-firefox List, mozilla.dev.planning group
With respect, are you guys nuts? You're killing a whole branch of your development because some people had issues with 64 bit plugins working on your 64 bit browser...You shouldn't do that...You should fix the damn documentation problem in your addons page and CLEARLY delineate between 32 and 64 bit plugins. I dunno if you guys have tried using your 32 bit version, but its memory management for any number of tabs over 34 SUCKS. Yes I read the pages, yes, I saw that theres all these neatokeen features that "improve the experience" and the like. I have a 32 bit VM with 32 bit firefox 17, and it CRAWLS with over 6 tabs open!

Bottom line..do you guys want to lose the browser wars? Do you want to become the Netscape Navigator of modern web browsers? This is a sure way to do it. Hell, even internet EXPLORER has a native 64 bit version.

I propose a new action. How about you tell your manager that you axed the 64 bit version and keep building it on the down low? All hail the 32 bit future? Tell ya what, have your IT dept take out the RAM in his computer and replace it with only 2GB of ram. Let's let him see that 32 bit isn't the way to go with your product.

wojon...@gmail.com

unread,
Nov 23, 2012, 6:06:17 AM11/23/12
to dev-apps-firefox List, mozilla.dev.planning group, Benjamin Smedberg
> Gregory


I want to be honest but that response reminds me from when apple released the iPhone 4 and people had connections issue due to the way the antenna and the user was holding the phone, and able told them "Your holding it wrong", your just told us "Your Browsing wrong".

Lets cut everything straight, Microsoft has stopped making 32bit operating systems , that means some time in the feature as usage of 32bit operating systems stop being connected to the internet, there will mostly be 64bit systems. I also think its been at least 2 to 3 years now, pretty much when windows 7 was launched you really stop seeing 32bit machines for sale I think just about every computer you can buy at a store is 64bit. So I know its a hard push and your going to have to do a lot of work but if you want to survive in the upcoming internet area your going need to need to stay on the bleeding edge like you use to.

wojon...@gmail.com

unread,
Nov 23, 2012, 6:08:28 AM11/23/12
to dev-apps-firefox List, mozilla.dev.planning group
When I was reading about this I was thinking, Firefox is open sourced, If we want 64bit then lets make 64bit well it turns out that its already out there with firefox, I am no big C developer but I think to allow code to work on 64-bit machines its mostly about how you compile and package it, its not always a full rewrite of your code. I mean maybe something like firefox has some memory mapping that they do interesting stuff with they will need to convert that or change some of the offsets.

sadi...@gmail.com

unread,
Nov 23, 2012, 2:04:06 PM11/23/12
to dev-apps-firefox List, mozilla.dev.planning group
On Friday, 16 November 2012 23:42:14 UTC+5:30, Benjamin Smedberg wrote:
> The Windows 64-bit builds are a constant source of misunderstanding and
>
> frustration, at least in the following ways:
>
>
>
> * Many plugins are not available in 64-bit versions
>
> * The plugins that are available don't work correctly in Firefox because
>
> we haven't implemented things like windowproc hooking, which means that
>
> hangs are more common
>
> * Crashes submitted by 64-bit users are currently not high priority
>
> because we are working on other things.
>
> ** This is frustrating for users because they feel (and are!) second-class.
>
> ** It is also frustrating for stability team triage because crash-stats
>
> does not easily distinguish between 32-bit and 64-bit builds in the
>
> topcrash lists and other reports. We basically ignore a set of nightly
>
> "topcrashes" because they are 64-bit only. (See bug 811051).
>
>
>
> For these reasons, I would like to propose that we disable the 64-bit
>
> Windows nightly builds. We should publish a custom update to move
>
> current win64 nightly users back onto win32.
>
>
>
> I also think we should consider disabling the win64 builders completely,
>
> but I'm also willing to shelve that proposal for another time if it is
>
> controversial. If we *don't* disable win64 hourlies, I plan on adding
>
> --disable-plugins to their configuration.
>
>
>
> --BDS
>
>
>
> Please followup to mozilla.dev.apps.firefox

You Lost one Die hard Firefox Nightly User .Time to shift to Chrome or Opera.If opera can bring x64 stable builds,why dont you ?.Its sure x64 is the future ,at one point in future you have to make x64 for windows for sure (Microsoft is actively working with 64 bit architecture with ARM holdings).I am pretty sure windows 8 slowly take tablet market.Eventhough MSFT are not allowing full native power in winrt (My view is they will relax ,when platform get mature atleast for some applications).So dont be lame and give insane excuses : how plugins will be ported if you dont provide what they want (i dont know the reason is serious enough),
Already we are losing market share to chrome ,dont be stupid that slowdown future development and market share.

Robert Kaiser

unread,
Nov 23, 2012, 9:08:20 PM11/23/12
to
dcl...@gmail.com schrieb:
> At home I use Debian Linux 64bits, with iceweasel 64bits. At work I use firefox (nightly) 64 bits. Now as with Debian, It's time to change web browser. It's time because AGAIN you force me to stop using your browser.

Nobody is ending support for Linux or Mac 64bit, those are released,
fully supported and will continue to be just that. All this is about
64bit-compiled Nightly for Windows only!

Robert Kaiser

jo...@johnholder.net

unread,
Nov 24, 2012, 1:22:28 PM11/24/12
to dev-apps-firefox List, mozilla.dev.planning group
This is a very bad decision. Goodbye Firefox, I'm sorry to see you go the way of Thunderbird.

The Mozilla PMs should be ashamed of themselves. They are alredy dragging their products behind, and this is worse.

It's just like Yahoo vs Google. Yahoo just gave up....and now has Mozilla.

ibis.s...@gmail.com

unread,
Nov 25, 2012, 1:14:53 AM11/25/12
to dev-apps-firefox List, mozilla.dev.planning group
* Many plugins are not available in 64-bit versions *
Really, that is because they are not going to release 64 bit versions until the 64bit version is released. They decided not to risk developing for something that the developers might drop b/c they did not trust the developers to finish what they start. (looks like they bet correctly)

* The plugins that are available don't work correctly in Firefox because
we haven't implemented things like windowproc hooking, which means that
hangs are more common *
Oh the beta version does not work b/c we have not finished making it and therefore we should stop making it. Are we in first grade here!?

* Crashes submitted by 64-bit users are currently not high priority *
because we are working on other things.
I think everyone knows that. There are a lot of things in life that are not high priority but just becuase they are not high priority does not mean we give up and never do them...

** This is frustrating for users because they feel (and are!) second-class.**
They are using a beta program! BETA I wonder if anyone knows what that means. They only really became and felt second class when they got tossed under the bus when development stopped.

** It is also frustrating for stability team triage because crash-stats
does not easily distinguish between 32-bit and 64-bit builds in the
topcrash lists and other reports. We basically ignore a set of nightly
"topcrashes" because they are 64-bit only. (See bug 811051). **
So basically a program your creating is not programed right and no one knows how to fix it. Lets get rid of the 32 bit version for the same reason then.

samye....@gmail.com

unread,
Nov 25, 2012, 4:37:41 PM11/25/12
to dev-apps-firefox List, mozilla.dev.planning group
Benjamin,

I am neither a developer nor a particularly skilled computer user, but I have taken advantage of the Windows 64-bit Nightly builds from the day they became available. Each morning I open the "About" window inside the browser to check for new updates, and in doing so I acknowledge how painfully stubborn this application can be. I understand that it is beyond beta, alpha. When something does not work I search for my own workaround. If there is none to be found, then I patiently wait for the following morning's update. There are nagging, aggravating annoyances, but I understand they may never be resolved. Or, some issues are addressed and others appear in their stead. Why do I do play patiently? Why do I use this version of the Firefox browser?

I use Nightly because it is there, because it is so much faster on my computer than the 32-bit version of Firefox, because I enjoy using this software in a thousand different ways like thousands of other users. How else would your team know what needs improvement when something goes awry unplanned and unknown until that moment?

Now. To address your "alert" to the community regarding discontinuing the 64-bit version of our favorite browser: What I believe, Benjamin, is this choice is arrogant, inappropriate, and above all short-sighted. Technology is perpetually moving forward in fits in starts. There is not one company nor organization nor community who can keep up with the changes as they occur. We must adapt and move forward as quickly as possible. There is no other option. It requires creativity, risk-taking and a deep understanding of what your customers/users expect and need. Opting to "take a break" leaves room for a competitor to do your job better and with more passion, costing the Mozilla movement customers/users and promoters (like me). From what I have come to understand is the most strident of your arguments being plug-in compatibility, but Benjamin, have we considered reaching out to the publishers of these applications about releasing compatible updates? Have we considered calling for volunteers to focus exclusively on a number of these issues. Have we discussed these challenges openly in an attempt to seek a resolution which benefits the entire community?

I have not heard of any of this until now. And I am extremely disappointed. This disappointment is not directed at any member of the Mozilla team. It is directed at myself, because there is the potential that I could have helped. And now, I no longer have the option.

Let us hope this is not true.

~Samye

m.g...@gmail.com

unread,
Nov 25, 2012, 5:27:39 PM11/25/12
to dev-apps-firefox List, mozilla.dev.planning group, Benjamin Smedberg
On Friday, November 23, 2012 12:06:18 PM UTC+1, wojon...@gmail.com wrote:
> Lets cut everything straight, Microsoft has stopped making 32bit operating systems

Unfortunately, that's not true, even Windows 8 has a 32-bit version...

Michał Gołębiowski

unread,
Nov 25, 2012, 5:54:22 PM11/25/12
to dev-apps-firefox List, mozilla.dev.planning group, Benjamin Smedberg
On Friday, November 23, 2012 12:06:18 PM UTC+1, wojon...@gmail.com wrote:
> Lets cut everything straight, Microsoft has stopped making 32bit operating systems

Robert Kaiser

unread,
Nov 25, 2012, 10:15:57 PM11/25/12
to
> Technology is perpetually moving forward in fits in starts. There is not one company nor organization nor community who can keep up with the changes as they occur. We must adapt and move forward as quickly as possible. There is no other option.

That's why we need to move forward and use our resources as efficiently
as possible. Using fewer bits per pointer address, i.e. 32bit instead of
64bit, is one way of moving forward there, as it enables us to generate
faster and more memory-efficient code. That's why we do it like that, at
least on Windows, where we are most sensible as most of our users are there.

Robert Kaiser

Michał Gołębiowski

unread,
Nov 26, 2012, 4:47:27 AM11/26/12
to
On Monday, November 26, 2012 4:15:59 AM UTC+1, Robert Kaiser wrote:
> That's why we need to move forward and use our resources as efficiently
> as possible. Using fewer bits per pointer address, i.e. 32bit instead of
> 64bit, is one way of moving forward there, as it enables us to generate
> faster and more memory-efficient code. That's why we do it like that, at
> least on Windows, where we are most sensible as most of our users are there.

I hope, though, that you're still dedicated to your OS X and Linux users!

Robert Kaiser

unread,
Nov 26, 2012, 11:36:26 AM11/26/12
to
Michał Gołębiowski schrieb:
> I hope, though, that you're still dedicated to your OS X and Linux users!

Sure, and we will continue to offer 64bit builds there. From what I
understand, our main focus on speed and efficiency is targeted on the
>90% of our users who are on Windows, though. That said, on Mac and
Linux, there are many cases where 64bit is actually faster (though 64bit
code takes up more memory than 32bit on every system), while that
doesn't seem to be the case so much on Windows.

Robert Kaiser




judahri...@gmail.com

unread,
Nov 27, 2012, 3:27:31 AM11/27/12
to
On Thursday, November 22, 2012 7:41:02 AM UTC-6, WaltS wrote:
>
> Ah, you know Chrome is only 32-bit.
>
Chrome has per-tab processes, which allows it to get around the 2GB RAM addressing limit. Firefox continues to be a single process.

judahri...@gmail.com

unread,
Nov 27, 2012, 3:53:59 AM11/27/12
to dev-apps-firefox List, mozilla.dev.planning group
Given that Firefox still lacks per-tab processes*, it now has an unnecessary 2GB RAM addressing limit on Windows. As web apps become increasingly demanding, the Windows build (all channels) will become decreasingly useful for heavy web multitasking.

So basically this decision kills Firefox on the Windows desktop, because you're effectively forcing the browser into obsolescence.

Chrome has per-tab processes and so avoids this issue despite being 32-bit only. Opera has an x64 build. IE has both x64 and per-tab processes. This leaves Firefox as the only (major) browser on Windows without per-tab processes or x64 capability. In other words, this a *huge* step *backwards* on *the biggest OS user base* in the world.

As a longtime Mozilla user and advocate, I am absolutely puzzled at this move. I must also strongly say that I feel very betrayed by it. The plugins reason is baffling: I use x64 Flash, Java, and Silverlight with no problems. The crash-stats issue also sounds fixable without unreasonable effort.

From my observation, a lot of the Firefox's Win64 issues are self-inflicted, e.g. trying to support outdated OSes https://bugzilla.mozilla.org/show_bug.cgi?id=795594#c24 Firefox used to symbolize the way forward for today's web, lately it seems the project is so concerned with the distant future (Firefox OS) and the past (XP support) it's forgetting the millions of users in the present.

I urge you to reconsider this move.

Boris Zbarsky

unread,
Nov 27, 2012, 4:21:13 AM11/27/12
to
On 11/27/12 3:53 AM, judahri...@gmail.com wrote:
> Given that Firefox still lacks per-tab processes*, it now has an unnecessary 2GB RAM addressing limit on Windows.

4GB, on a 64-bit system.

> So basically this decision kills Firefox on the Windows desktop

Uh... This decision changes nothing long-term: the plan is still to do
a 64-bit Windows Firefox. Just not next month.

> In other words, this a *huge* step *backwards*

Note that we're going from not having a shipping 64-bit Firefox on
Windows to ... not having a shipping 64-bit Firefox on Windows. No
actual change for non-Nightly users.

Again, the question is whether there should be Nightly builds given that
there is no short-term plan to ship anything based on them.

> I urge you to reconsider this move.

What's your concrete proposal? Keep shipping nightlies while having no
plan to actually ship a release (that is, the status quo)? Or something
else?

I understand that you feel strongly about this issue, but I think you're
arguing based on faulty assumptions, unfortunately...

-Boris

Mr. T

unread,
Nov 27, 2012, 6:27:54 AM11/27/12
to
Am Dienstag, 27. November 2012 10:21:14 UTC+1 schrieb Boris Zbarsky:
> > So basically this decision kills Firefox on the Windows desktop
>
> Uh... This decision changes nothing long-term: the plan is still to do
> a 64-bit Windows Firefox. Just not next month.

Yea "long-term", i'm reading that since 2010.
The hard truth is, Mozilla is not willing release 64-bit Firefox on Windows.

Wayne

unread,
Nov 27, 2012, 7:08:57 AM11/27/12
to
Chrome is also a pig as the number of tabs increases. So, Chrome is not
the solution/alternative to 64bit (or 32bit) firefox in this scenario of
user having lots of tabs, unless you have a tricked out computer. (but
fine for the average user with only a couple dozen tabs or so)

The pertinent point however, is that Firefox is seeking an effective
approach to implementing multiple process, not just going for an easy
slam dunk. I am happy to wait, so far, for a good solution.

lew...@gmail.com

unread,
Nov 27, 2012, 9:41:17 AM11/27/12
to dev-apps-firefox List, mozilla.dev.planning group
First of all, the only major browsers to have abandoned XP are Internet Explorer 9+ and Safari 6+; Opera, Chrome, and Firefox still all work on XP.

Also, just go ahead and use the Waterfox builds if you prefer 64-bit; I mean it's not as good as Opera 12 or IE10, in that it doesn't use both 64- and 32-bit plugins, but at least you don't need to migrate your Firefox profile to use it: http://www.waterfoxproject.org/

Another option is Pale Moon, but that one does require you to rebuild your profile, and it lags behind the Firefox release schedule even further than Waterfox does (currently Firefox is at 17, Waterfox is at 16, and Pale Moon is at 15, but they usually end up synching with the stable releases at some point): http://www.palemoon.org/palemoon-x64.shtml

Robert Kaiser

unread,
Nov 27, 2012, 11:53:11 AM11/27/12
to
judahri...@gmail.com schrieb:
> On Thursday, November 22, 2012 7:41:02 AM UTC-6, WaltS wrote:
>>
>> Ah, you know Chrome is only 32-bit.
>>
> Chrome has per-tab processes, which allows it to get around the 2GB RAM addressing limit. Firefox continues to be a single process.

As a note, when you are running a 64bit Windows version, the limit for
32bit processes such as Firefox is 4GB, not 2GB.

Robert Kaiser

fbrf...@gmail.com

unread,
Nov 28, 2012, 2:26:39 PM11/28/12
to

> What's your concrete proposal? Keep shipping nightlies while having no
>
> plan to actually ship a release (that is, the status quo)? Or something
>
> else?
>

Keep shipping nightlies. They work. They're like 99.999% stable. People use them.

Randell Jesup

unread,
Dec 7, 2012, 6:51:22 PM12/7/12
to
>On 11/21/12 8:19 AM, Benjamin Smedberg wrote:
>> On 11/16/2012 1:11 PM, Benjamin Smedberg wrote:
>>>
>>> For these reasons, I would like to propose that we disable the 64-bit
>>> Windows nightly builds. We should publish a custom update to move
>>> current win64 nightly users back onto win32.
>> Thank you to everyone who participated in this thread. Given the
>> existing information, I have decided to proceed with disabling windows
>> 64-bit nightly and hourly builds. Please let us consider this discussion
>> closed unless there is critical new information which needs to be
>> presented.
>
>For those running into the 32 bit memory ceiling, you have a legitimate
>complaint: your usage pattern of Firefox may no longer be supported by 32
>bit builds. I don't like it when someone forces me to change either, so I
>sympathize with you.
>
>Many of the people hitting this memory ceiling are hitting it because they
>have many tabs open - possibly hundreds of tabs. There are a number of
>things that can be done to abate this.

>The obvious solution: don't have so many tabs open! May I suggest using
>some form of bookmarking or read it later instead. There are numerous
>add-ons available if the features in Firefox itself aren't
>satisfactory.

I'm a tab hoarder, and I'm afraid I have no intention in joining a 12-step
program to reduce tab usage... :-) For years, my tab numbers have been
limited by memory/performance. In the old pre-BarTab days of 3.5ish, I
was limited on XP to around 100-125 tabs, and beyond that both reloads
were too painful and time between running out of memory was too low.

I typically have 400+ tabs on Windows, and 900-1000 tabs on linux64.
The Awesome Bar is actually encouraging this - it makes it trivial to
use tabs as a fast-access mechanism (and not have to wait for something
to load); and tabs also act as a way to group related bits of research,
and as a "reading queue" - open things I want to read, but don't have
time to read now - if I don't, I may not find the link again. I don't
want to bookmark them, just keep them until I read them. I might start
reading, then be pulled off for other things, etc.

>Another solution is to restart your browser periodically. Firefox 13
>introduced on-demand tab loading. So, when you restart your browser, tabs
>aren't loaded until you actually use them. The relevant preference in
>about:config is browser.sessionstore.restore_on_demand. It's "true" by
>default. Be sure you haven't accidentally changed it to false.

Without that (and BarTab before it), I'd still be limited to a 100 or
200 tabs - and even then restarts would be Pain. I average 100-200
loaded tabs after a week or so.

>In bug 675539 (https://bugzilla.mozilla.org/show_bug.cgi?id=675539), we are
>tracking a feature to automatically unload unused tabs, freeing memory in
>the process. Once this lands, this should (finally) keep the memory
>footprint of Firefox in check for tab-heavy users.

I doubt that will ever be viable (and yes I follow that bug). Too many
tabs are ones you don't want to auto-unload (and yes, I know if I
restart it causes the same problem). Most of the time it'd be fine, but
the occasional pain would be large. Or you have to set such a large
timeout that it doesn't really help you much. Maybe I'm wrong, but
we'll see. It's a great idea, if it weren't for the downsides. And if
I have to manicure a whitelist/blacklist, it won't happen.

We may eventually have to evolve another paradigm for browsing; we've
hit the limits of the tab paradigm. As to what - well, if I knew
that... :-)

Eventually, we'll move to a 64 bit exe. The question is when.

--
Randell Jesup, Mozilla Corp
remove .news for personal responses
0 new messages