Turning off win64 builds

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.

On 11/16/2012 1:21 PM, Andrew Joakimsen wrote:
> I think it would be better to ensure crash-stats distinguishes between platforms. It seems the user can deal with everything else given that we're talking about prerelease software.

It's not really a question of whether they *can*. It's a question of
whether that is actually *helpful*. I'm saying that it's clear we're not
going to be shipping a release win64 build any time soon, with our
current focus on Metro and Firefox OS. Bugs that are win64-specific
aren't going to get any attention and are just going to frustrate
everyone, testers and developers alike.

On Friday, 16 November 2012 18:22:03 UTC, Andrew Joakimsen wrote:
> I think it would be better to ensure crash-stats distinguishes between platforms. It seems the user can deal with everything else given that we're talking about prerelease software.

I agree whole-heartedly about switching off Win64 Nightly builds - crash-stats are just the tip of the iceberg.

> I think it would be better to ensure crash-stats distinguishes between platforms. It seems the user can deal with everything else given that we're talking about prerelease software.

As one of the main consumers of crash-stats, I have never had a problem
with the more experimental stuff like this just appearing in topcrashes
for Nightly (as it does not appear on other channels anyhow), esp. as I
was always under the impression that we will ship win64 at some point.
If that's no target at all for the foreseeable future, we should just
disable the nightlies for this completely.

On 11/16/2012 12:35 PM, Benjamin Smedberg wrote:
> It's not really a question of whether they *can*. It's a question of
> whether that is actually *helpful*. I'm saying that it's clear we're not
> going to be shipping a release win64 build any time soon, with our
> current focus on Metro and Firefox OS. Bugs that are win64-specific
> aren't going to get any attention and are just going to frustrate
> everyone, testers and developers alike.
>
> crash-stats is just a symptom of the problem.
>
> --BDS
>

This assumes that those 64-bit users have access to Windows 8 and
FirefoxOS. This boils down to developer concern only.

Testers are already frustrated that many valid bugs regardless of 64 or
32b-bit remain unfixed for extreme periods of time or indefinitely.

> 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 personally would not go back to 32-bit Nightly. After the electrolysis project was canceled, Disabling Win64 build will be the last disappointment to me by Mozilla. I would no longer using/support Firefox.

Am Montag, 19. November 2012 01:38:08 UTC+1 schrieb Matthew Turnbull:
> Unless you're running out of virtual memory, there's no advantage to be
> using a 64bit build. In any other case, you are usually better off
> running a 32bit build.

Then explain me, why MS run IE 10 Metro on Win 8 x64 by default as 64bit application? The Manager Processes of the IE 10 non Metro always run as 64bit processes and the Content as 32bit Processes, but by activate "Enable Enhanced Protected Mode" the Content Processes also run as 64bit.

On 11/17/2012 10:45 PM, Omega X wrote:
> On 11/16/2012 12:35 PM, Benjamin Smedberg wrote:
>> It's not really a question of whether they *can*. It's a question of
>> whether that is actually *helpful*. I'm saying that it's clear we're not
>> going to be shipping a release win64 build any time soon, with our
>> current focus on Metro and Firefox OS. Bugs that are win64-specific
>> aren't going to get any attention and are just going to frustrate
>> everyone, testers and developers alike.
>>
>> crash-stats is just a symptom of the problem.
>>
>> --BDS
>>
>
>
> This assumes that those 64-bit users have access to Windows 8 and
> FirefoxOS. This boils down to developer concern only.

It doesn't presume anything of the kind. It does assert that 32-bit
Firefox builds work for those users, and in many important cases work
better than 64-bit builds do.

For the purposes of this thread, it is already a done decision that we
aren't going to ship 64-bit Windows Firefox builds in the first half of
2013, and probably not at all in 2013. In the meantime, we aren't going
to fix crashes or plugin bugs that only affect 64-bit builds. Those
decisions have already been made. The only question to decide here is
whether the existing 64-bit Windows nightlies provide any value to the
project.

>
> Testers are already frustrated that many valid bugs regardless of 64
> or 32b-bit remain unfixed for extreme periods of time or indefinitely.
>

No large software is ever going to be able to fix all its issues. We
have limited resources and basically unlimited demands. That's why
module owners and release drivers prioritize which ones are the most
important and urgent, and we try to fix those. Bugs which affect win64
builds are inherently lower priority to the project.

Bug tracking?
Let's say that Moz starts working on the x64 in 2014 Q1.
If they stalled the x64 builds completely, they may have to spend months (or at least, weeks) on bug hunting, regression range searching and such things.
If they keep shipping the builds, the testers could file a list of bugs and regressions related to Win x64, by the time Moz starts to work on those builds officially.

On 11/19/2012 11:52 AM, Srap wrote:
> Bug tracking?
> Let's say that Moz starts working on the x64 in 2014 Q1.
> If they stalled the x64 builds completely, they may have to spend months (or at least, weeks) on bug hunting, regression range searching and such things.
> If they keep shipping the builds, the testers could file a list of bugs and regressions related to Win x64, by the time Moz starts to work on those builds officially.

They could, yes. That's a tradeoff we need to decide on. I believe that
the pain to our QA and eng community is greater than the potential benefits.

Also, maybe the project could have a discussion in Q4 in 2013 about turning
64-bit builds on again to have testers start finding bugs again (this is
not a guarantee that they will). But that's a long time and 64-bit testers
are inevitably going to be frustrated in the meantime, knowing that the
bugs they report aren't going to be fixes for 1+ year(s).
(Disclaimer: I'm just a random guy and am in no way affiliated with
Mozilla.)

On 11/18/12 2:30 PM, Mr. T wrote:
> I personally would not go back to 32-bit Nightly. After the electrolysis project was canceled, Disabling Win64 build will be the last disappointment to me by Mozilla. I would no longer using/support Firefox.
>

You will need to use IE then, because Google does not support 64-bit
Chrome builds for Windows [1] or Mac OS X [2]. Opera has experimental
64-bit builds for Windows [3], but AFAIK they have not been updated
since February.

Apple no longer supports Windows as of Safari 6, so it doesn't really
matter if they had 64-bit builds for Windows or not.

On 2012/11/17 3:11, 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

As long as I know, the following major plugins support Win64 NPAPI.

- Flash
- Java
- Silverlight
- Microsoft Office 2010

Of course, Acrobat and Quicktime don't.

> * 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

DLL interceptor have been implemented on Win64. Doesn't this work on
the latest code? At least, when I implemented it, it worked.

> * 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).

+1. Socorro should separate per CPU, too. I think linux x86 and linux
x86-64 should be same, too.

> 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
>

On 11/16/2012 1:11 PM, 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

With 64bit an several addons, flash, etc I haven't experienced the
instability you describe over the last 6 months. In the 6 months prior
there was instability, but not 64bit specific. OTOH, I may not be a
typical trunk user - I am not normally doing lots of flash, facebook,
etc, on my 64bit instance.

> * Crashes submitted by 64-bit users are currently not high priority
> because we are working on other things.

I assume you mean 64bit windows - and don't see why anyone would have a
problem with that. It's just reasonable triaging.

So what has mainly prompted the change in thinking? Have 64bit
crashes+hangs gotten worse recently? Or are we mainly just hitting more
workflow issues in Socorro (mentioned below) or elsewhere?

> ** This is frustrating for users because they feel (and are!) second-class.

I am not sure I see the frustration you suggest reflected in our bug
reports [1] - it doesn't seem disproportionate. Besides, when running
trunk users implicitly sign up to be broken in every possible way.

> ** 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).

This frustration I can perhaps sympathize with. However, we routinely
ignore some signatures for various reasons - caused by AV, malware,
addons, etc. So how is 64bit crashes different from these, and what
quantity of top 30 crashes or top 100 crashes are we talking about?

> 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.

might it be sufficient to disable crash reporter by default in 64bit builds?

> 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.

You might want to initially only do the later, in case the win64
question is revisited in the future.

datapoint - I first turned to 64bit builds about a year ago because the
32bit builds couldn't handle the number of windows and tabs I was using.
That's the only reason I can think of that would require a user to need
64bit on windows. And memshrink has made a dent in reducing that need.

Having said all the above, if the odds are slim to none of us ever
releasing 64 bit windows build with the current code base, then I think
the bottom line here is there is little no long term value to providing
said builds and it just fuels speculation and questions of "when are
they ever going to release 64bit on window?"

But if the odds are more than slim, then perhaps we want to keep them
available for people to use, and continue to be OK with 64bit windows
bug reports not getting the same level of attention that other bugs get.

Also, for the record: threats are generally not very effective at
convincing people. Do feel free to bring up constructive points,
especially if you've taken the time to do a little research -- but if
your only argument is a threat, then please don't post.

Well let me question what has happened to Mozilla. Because Mozilla was once an industry leader for their web browser and other software. It used to be a progressive company challenging itself, innovating, and moving the market forward.

Now Mozilla is backing away from what it was? Will not push the entire web browser market into the 64-bit market? Taking the cowardly way out by just stating 'they aren't, so why should we?'

Did Google scare you out of being an industry leader? I have news for you, you will always play catch-up to Google if you keep this mindset. Even with Intel's help with River Trail you should realize any gains above Chrome will be temporary on 32-bit OS's. Google will get ahold of the tech and improve it with due-time. So instead of following their lead act like the leaders Mozilla used to be and lead browsing into the age of 64-bit browsing.

To gain what? Just cause a technology exists, doesn't mean it's the
perfect target for any kind of application.
It's pretty clear the move to 64 bit doesn't bring interesting benefits
to browsing as of now, so why should one spend resources to innovate
towards something that brings no tangible benefits?
In any healthy project there must be prioritization based on cost VS
benefit, and this is losing the race. In 5 years may be different, but
we live now.

No, it's still the same as it "was". The problem from your point of
view is that it doesn't see "push web browsers to be 64-bit" as a
worthwhile goal in itself and is instead focusing on other goals, like
changing the app distribution model, getting not-as-locked-down devices
to people, and various other things.

The 64-bit thing might be a nice-to-have, but it's just a lower priority
than other things that need challenging, innovating, and moving forward.

All of this discussion is academic unless the people advocating for
64-bit have a concrete plan for what other things should NOT be done to
do that. Or who will start contributing time who isn't right now, at
the very least.

2012. november 20., kedd 18:13:29 UTC+1 időpontban superg...@gmail.com a következőt írta:
> it be a shame to disable 64 bit nightly its the only non internet explorer 64 bit browser to choose (other then waterfox but heck its just a variant of the current 64 bit nightly Firefox)

1. Opera offers stable x64 Win builds since 12.0, as it was mentioned here before.
2. Waterfox is built from the source of the stable version of FF, means " WF16's father is FF16". Also, Waterfox isn't the only unofficial x64 variant.

Wayne schrieb:
> I assume you mean 64bit windows - and don't see why anyone would have a
> problem with that. It's just reasonable triaging.

Yes, and I agree.

> might it be sufficient to disable crash reporter by default in 64bit
> builds?

That would lose them from our Nightly stability testing audience, which
I wouldn't want to have from my POV in stability tracking.

IMHO, we should disable Win64 Nightly builds, but it may make sense to
keep hourlies along (either without tests or with only one test suite
that makes sure it basically runs) if we want to make sure it keeps
building and running to some degree.

We should revisit this when we are ready to make a commitment to
actually ship and maintain Win64.

chaosfre...@gmail.com schrieb:
> Now Mozilla is backing away from what it was? Will not push the entire web browser market into the 64-bit market? Taking the cowardly way out by just stating 'they aren't, so why should we?'

No, Mozilla is moving forward. Due to a list of reasons, Windows 64bit
builds are slower in several things and need more memory than 32bit
versions, so they are holding us back form being fast and slim right now.
Creating those builds was an experiment and we did not see any real
benefits so far from it, so we feel confident with continuing to improve
the 32bit builds, as we know that's the best way to provide fast,
memory-efficient and powerful browser to Windows users for at least the
next year. We have only limited resources and right now it's best to
focus them on what brings the best efficiency to the vast majority of
people on the web, and for now, that's best achieved with 32bit builds
on Windows.
The code is there and it is all open, and we'll be happy about patches
to keep it working well, as we probably will revisit this topic at some
point, when the surroundings change (e.g. on Mac, we discovered that
32bit system libraries often don't get loaded for anything, so 64bit
builds are much faster to launch - this is not true at all on Windows at
this point, but may be some time in the future). Because of us being
such an open project, it's also easily possible for someone (e.g.
Waterfox) to provide unofficial variants compiled to 64bit, or for
people to compile 64bit builds themselves and use them.

Note that this doesn't mean we don't support 64bit OSes well, on the
contrary, even a 32bit Firefox profits from 64bit version of Windows,
e.g. in being able to use more maximum memory (4GB instead of 3GB) and
probably also other improvements. So, we are actually supporting 64bit
Windows systems well, even if our builds themselves are not compiled as
64bit binaries.

And note that the example of Chrome was only brought to underline that
even they, with their media focus on speed and their larger memory
requirements, came to the same conclusions as us - independently of what
we found out. And contrary to them, you can compile our complete code
yourself if you like to, as outlined above.

It's not like we don't care about progress, in fact, this helps us to
progress faster and be more efficient.

spec...@gmx.de wrote:
> Then explain me, why MS run IE 10 Metro on Win 8 x64 by default as
> 64bit application? The Manager Processes of the IE 10 non Metro
> always run as 64bit processes and the Content as 32bit Processes,
> but by activate "Enable Enhanced Protected Mode" the Content
> Processes also run as 64bit.

IIRC, on Windows 8, 32-bit system libraries are not loaded at all unless/until a 32-bit application loads them. So, it is likely that the first 32-bit application opened on Windows 8 will have to pay a large startup penalty purely for being 32-bit. Thus, it might make a lot of sense for the IE chrome process to be 64-bit, so it can start up right away. But, I guess that the memory penalty of being 64-bit hurts too much to make the content processes 64-bit by default, even though the 64-bit content processes are more secure.

Anyway, I agree with you that it is likely that we will sometime have to be 64-bit on Windows by default. But, we just have other things that are higher priority now.

On Friday, November 16, 2012 7:12:13 PM UTC+1, Benjamin Smedberg wrote:
> * 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

On Tuesday, November 20, 2012 3:05:44 AM UTC+1, Makoto Kato wrote:
> DLL interceptor have been implemented on Win64. Doesn't this work on
>
> the latest code? At least, when I implemented it, it worked.
Since it seems there's some disagreement or at least confusion on this point, can anyone confirm the status of windowproc hooking and/or DLL interception on win64?

On 11/20/2012 4:21 PM, Robert Kaiser wrote:
> Wayne schrieb:
>> I assume you mean 64bit windows - and don't see why anyone would have a
>> problem with that. It's just reasonable triaging.
>
> Yes, and I agree.
>
>> might it be sufficient to disable crash reporter by default in 64bit
>> builds?
>
> That would lose them from our Nightly stability testing audience, which
> I wouldn't want to have from my POV in stability tracking.

Let me rephrase my comment about disabling crashes so I am clear - I
mean only windows 64bit. In which case, one issue mentioned by smedberg
is gone - the issue which helped push win64 to the chopping block. A
user could always reenable it if needed. Or we could throttle them.

> IMHO, we should disable Win64 Nightly builds, but it may make sense to
> keep hourlies along (either without tests or with only one test suite
> that makes sure it basically runs) if we want to make sure it keeps
> building and running to some degree.
>
> We should revisit this when we are ready to make a commitment to
> actually ship and maintain Win64.
>
> Robert Kaiser

While the question of whether to the disable them is worth evaluating,
having posted the reasons to disable (negatives) without including the
reasons why it was originally decided to keep them (positives) results
in the one sided perspective.

If we are going to revisit doing win64 in one year then, pending
feedback to my previous questions, I am in favor of keeping these builds
for users.

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.

Banjamin, i would object. Given that it is hard to find 32-bit machine nowdays this decision does not seem wise. We know that most of the users run 32-bit browser build. However, do we have statistics about on which CPU do they run it?

> On 11/20/2012 4:21 PM, Robert Kaiser wrote:
>> Wayne schrieb:
>>> I assume you mean 64bit windows - and don't see why anyone would have a
>>> problem with that. It's just reasonable triaging.
>>
>> Yes, and I agree.
>>
>>> might it be sufficient to disable crash reporter by default in 64bit
>>> builds?
>>
>> That would lose them from our Nightly stability testing audience, which
>> I wouldn't want to have from my POV in stability tracking.
>
> Now I'm confused - You don't want to lose win64 crashes? But you don't
> want win64 crashes poluting topcrash or elevating 32bit signatures? I'm
> missing something.

I don't want to lose crashes from any legitimate Nightly users we have.
We already have fewer users than I'd like to have for Nightly crash
testing, I don't want to exclude a significant part of those from
reporting crashes to us.

On Tuesday, November 20, 2012 1:39:04 PM UTC-8, Robert Kaiser wrote:
> And note that the example of Chrome was only brought to underline that
>
> even they, with their media focus on speed and their larger memory
>
> requirements, came to the same conclusions as us - independently of what
>
> we found out. And contrary to them, you can compile our complete code
>
> yourself if you like to, as outlined above.

To be honest, Chrome is a *multi-process* browser, each of which can use up to 2GB, while Firefox is still single-process.

On Nov 20, 4:05 pm, Brian Smith <bsm...@mozilla.com> wrote:
> IIRC, on Windows 8, 32-bit system libraries are not loaded at all unless/until a 32-bit application loads them. So, it is likely that the first 32-bit application opened on Windows 8 will have to pay a large startup penalty purely for being 32-bit. Thus, it might make a lot of sense for the IE chrome process to be 64-bit, so it can start up right away. But, I guess that the memory penalty of being 64-bit hurts too much to make the content processes 64-bit by default, even though the 64-bit content processes are more secure.
>
> Anyway, I agree with you that it is likely that we will sometime have to be 64-bit on Windows by default. But, we just have other things that are higher priority now.
>
> Cheers,
> Brian

I agree with the previous poster... you are telling me you don't want me as a user. If I must use 32-bit, I'll use Chrome. Maybe I'll go look closer at Opera. Whatever, Mozilla projects are no longer an option in my world.

I know Mozilla has limited resources. Now since several years you have stable x64 nightly builds. In the near/far future there will be only x64 OS systems. If you drop those nightly builds now, it gonna take you a huge effort in development and testing when you want to support x64 systems again. So, isn't it cheaper to just build the x64 along with the x86 nightlies?

You should also see other benefits in x64 builds. Mainly to have plenty of nightly testers, which give you also less bugs in 32 bit builds.
As a user I can tell you that I often have 50-100 open tabs. Especially when I'm doing research. FF in those cases eats about 3.5 to 4GB of RAM. This is totally fine on x64 systems, but you know about the memory limit on 32bit systems...

I quite like FF, but doing heavy browsing is one of my crucial requirement to a browser. If that in the near future will not be possible in FF any more, I don't see any other solution, than just so switch browser.

On Friday, November 16, 2012 12:12:13 PM UTC-6, 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

Then implement it! It would surely help with stability with both x86 and x64.

> * Crashes submitted by 64-bit users are currently not high priority
> because we are working on other things.

This is known, but as x86_64 is only available in windows pre-releases or nightly builds anyway, if users can't handle this extra delay and instability, perhaps they shouldn't be using a pre-release browser in the first place.

> ** This is frustrating for users because they feel (and are!) second-class.

So, instead, you want to make them even less? Second-class with delayed support is better than ignored with no support at all.

> ** 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 fix crash-stats. And just because some crashes are 64-bit only NOW doesn't mean they're going to be 64-bit only in the future. Oh, and aren't you building 64-bit for Linux and OSX too? Does that mean that x86_64 support on those platforms is also going away?

> 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.

And for these refutations, I would like to counter that we keep the 64-bit Windows nightly builds.

> 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.

So, essentially, you've personally had enough dealing with some uninformed users that insist on using a pre-release browser and expecting stability and high-end support from it, and are thus throwing out the baby with the bathwater to ensure that rather than dealing with the Windows x86_64 issues as they come up, you're passing them down the line for someone to deal with some nebulous time in the future, when you decide to re-enable x86_64. And how would this decision affect building against WinRT/ARM? I'm sure that's something you would also like to do in the future.

>> 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.
>

On Sunday, November 18, 2012 7:38:08 PM UTC-5, Matthew Turnbull wrote:
> Unless you're running out of virtual memory, there's no advantage to be
> using a 64bit build. In any other case, you are usually better off
> running a 32bit build.

/me raises hand.

Memory usage is on the rise. Years ago, it used to be rare for Firefox to exceed 1GB of memory usage, but now, Firefox regularly exceeds 4GB. I'll grant that most people don't have as many tabs open as me and don't use nearly as much memory as me, but I wouldn't be surprised if, some time down the road, that 4GB limit starts becoming a more mainstream problem. Chrome has separate processes to work around this, but without e10s, 64-bit builds are the only recourse for me on Gecko.

Could you please at least keep creating builds? Make them available only as zips, with excessive numbers of disclaimers, if necessary. I don't care that the 64-bit builds are not perfect or that they are not fully supported, and if the builds are discontinued, I'll compile them myself if I have to, but that's a bloody hassle, so at least save us that bit of trouble.

On Friday, November 16, 2012 7:12:13 PM UTC+1, 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

And ? So what ?
The first 64 bits version of IE doesn't have any plugins. Now that more persons use it, plugins are coming.

> * 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

Implement them, we don't care having tons of plugins, we need a stable and complete 64 bits version first.

> * 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).

Add a separation between 32 and 64 bits version (if possible) in your crash report system, and treat them equally with the 32 bits version.

> 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.

For me, the problem is that it's a pain to download a 64 bits version of Firefox (or Thunderbird). Why can't I download them easily from www.mozilla.com ?
More users, more reports, more plugins.
Oh, and yes, disable plugins in 64 bits versions is a good idea, just put an advice to warn users that plugins have been disabled for stability reasons in this version of Firefox/Thunderbird.

32 bits are daying, even on Windows, Firefox and Thunderbird must have a 64 bits version on every OS that can handle it.

Den fredagen den 16:e november 2012 kl. 19:12:13 UTC+1 skrev Benjamin Smedberg:
> 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.
>
>
>

> * 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

Then implement it! It would surely help with stability with both x86 and x64.

> * Crashes submitted by 64-bit users are currently not high priority
> because we are working on other things.

This is known, but as x86_64 is only available in windows pre-releases or nightly builds anyway, if users can't handle this extra delay and instability, perhaps they shouldn't be using a pre-release browser in the first place.

> ** This is frustrating for users because they feel (and are!) second-class.

So, instead, you want to make them even less? Second-class with delayed support is better than ignored with no support at all.

> ** 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 fix crash-stats. And just because some crashes are 64-bit only NOW doesn't mean they're going to be 64-bit only in the future. Oh, and aren't you building 64-bit for Linux and OSX too? Does that mean that x86_64 support on those platforms is also going away?

> 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.

And for these refutations, I would like to counter that we keep the 64-bit Windows nightly builds.

> 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.

On Friday, November 16, 2012 7:12:13 PM UTC+1, 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

And ? So what ?
The first 64 bits version of IE doesn't have any plugins. Now that more persons use it, plugins are coming.

> * 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

Implement them, we don't care having tons of plugins, we need a stable and complete 64 bits version first.

> * 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).

Add a separation between 32 and 64 bits version (if possible) in your crash report system, and treat them equally with the 32 bits version.

> 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.

> 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.
>
>
>

>> 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.

Am Freitag, 16. November 2012 19:12:13 UTC+1 schrieb Benjamin Smedberg:
> 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

ROFL... I´ve been waiting für 17 stable versions and now you quit development of the 64bit version? WHAT THE F*** !!! Stop developing BULLSHIT features, themes and fuckin Mobile Versions for Android and other crap like that and focus on what matters - OS COMPLIANT BUILDS... 32 BIT OS´es will be gone someday soon so what hell are you thinking you´re doing over there? Thats not why i bought my Firefox Shirt and some other merchandise Years ago... Thats also not the reason i donated money for Firefox/Thunderbird development. I thought you´d be the right choice for all the PC platforms I am using but - NOOOOOOOOOOT

> I don't like it when someone forces me to change either, so I sympathize
> with you.

RAM is bloody cheap these days. I have 16GB, so I'm perfectly content to let
Firefox run for several weeks without restarting (yes, even Nightly, which I
suppose is a testament to its stability, and yes, I know, I shouldn't be
doing that, but I don't care) and let its memory usage creep up to 8GB or
more. I don't want to have to worry about how many tabs I have open, how
long it's been since I last restarted, what its memory usage is, etc. Nor do
I want to start to have to worry about these things again. This is what 64
bits gives me. I'll concede that I'm a rare specimen here.

And frankly, the OOM crashes and the high-CPU thrashing that Firefox's
memory management goes through when it gets close to the limit are far worse
problems than whatever little 64-bit minutiae that I don't even notice.

> 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.

And that's the other thing: memory usage can increase over the course of
several days to uncomfortable levels even with relatively few tabs, even
with well-behaving websites, even with no addons. Yes, I know, I should file
a bug. Which I would, if I had something more useful and concrete.

Anyway, I'm not sure what the value of completely turning off hourlies or
even nightlies are. If you don't want to send the wrong message to
end-users, that's easy: make it available only as zips and/or attach big
scary disclaimers. If you don't want to spend resources to bother with
tests, then don't bother with tests. If you don't want to spend resources to
bother with crash stats, then don't bother with crash stats. If you don't
want to spend resources to fix bugs that break 64-bit builds, then don't fix
them and wait for a 64-bit user to get impatient enough to fix it
themselves. All I ask is that the build servers still compile it because
compiling it locally is a slow, painful process, as everyone knows.

On 2012-11-22 5:17 PM, Kai Liu wrote:
>> 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.
>
> And that's the other thing: memory usage can increase over the course of
> several days to uncomfortable levels even with relatively few tabs, even
> with well-behaving websites, even with no addons. Yes, I know, I should
> file a bug. Which I would, if I had something more useful and concrete.

A good way to file such bugs is to load about:memory?verbose in a tab,
copy everything that it reports into a text file, and attach it to the bug.

On 11/22/2012 9:03 AM, Armen Zambrano G. 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.
>
> 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.

Yes, I am aware of the recommendation from March; I was very involved in
making that decision to begin with. At that time, we were still actively
working on electrolysis, and the plugin/stability team(s) were not
overwhelmed with the Flash protected mode debacle; the Windows team was
not actively prioritizing the Windows Metro project. Given the people
constraints imposed by those projects as well as Firefox OS, we do not
have the ability to fix the remaining bugs in win64 builds or turn them
into a production release. We need to focus our testing community on the
things which are most important.

If we had infinite resources, we certainly would continue with win64
builds now.

We will revisit our priorities and probably will resume win64 builds in
the future if we decide that focusing on win64 is an important project
priority. But almost certainly not until the middle of 2013.

> I know Mozilla has limited resources. Now since several years you have stable x64 nightly builds. In the near/far future there will be only x64 OS systems. If you drop those nightly builds now, it gonna take you a huge effort in development and testing when you want to support x64 systems again. So, isn't it cheaper to just build the x64 along with the x86 nightlies?

We support 64bit Windows perfectly fine with the 32bit builds. And even
building 64bit builds and running automated tests on them (without which
we'd never ever release nightly builds) uses considerable resources.
Monitoring their stability uses even more resources.

> To be honest, Chrome is a *multi-process* browser, each of which can use up to 2GB, while Firefox is still single-process.

Yes. I'm pretty sure we'll need to revisit that again as well at some
point. The large problem why we decided against doing this for now is
that making Firefox multi-process breaks a really significant amount of
exisiting add-ons.

Isn't the visibility and early warning on code issues worth the occasional frustrations with triaging topcrashes? There's basically a bunch of people happy to run 64bit nightly and if it works well enough to be their primary browser why not let them continue to use it and flush out code issues?

Even if native win64 is never officially supported that's no excuse to allow bad code in. You'll always want to build for other platforms and anything that helps platform specific code to fail early is a good thing.

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!!

El viernes, 16 de noviembre de 2012 19:12:14 UTC+1, Benjamin Smedberg escribió:
> 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

Re memory use - Firefox 32 bit is quite OK. I sometimes close the browser
because 529 tabs currently uses about 600MB. But it only takes about 5-10
sec to reopen it. Its not such a big deal. IE or Chrome will use half
that memory for half a dozen tabs... tolerable with 4GB memory on Windows
7. Windows Live Mail uses the next amount of memory - usually about
200-400MB

The main problem is Panorama (Grouped tabs) it makes it so easy to file tabs
away but not so easy to scroll thru and close them. Eg if a group has
enough tabs for the icons to fill the screen then the "X" button disappears
from them and the group is too big to use the UI to close them.

On 11/23/12 3:10 AM, smo...@gmail.com wrote:
> Even if native win64 is never officially supported that's no excuse to allow bad code in.

It may be if the bad code in win64-only. The most recent instance of
this was a bug that seems to be cause by win64 PGO that caused a
performance improvement to be backed out, slowing things down on all
other platforms too.

And obviously win64 PGO bugs in MSVC have no effect whatsoever on other
platforms...

You say, that you stop providing win64 builds partly because plugins are not available in 64bit versions and thus the user experience would be bad.
Now, that you decided to chicken out of providing a win64 build, we really have a chicken-egg problem going on. Companies like Adobe can further delay any effort in making a 64Bit Flash plug-in or a 64Bit adobe reader plugin. Isn't that a pretty bad strategy?

Also, what happened to the plugin-container concept? Shouldn't you be able to run 32Bit plugin in an external process? I believe opera does it like that. Or are you saying that doesn't work properly at the moment?

Also, what's the number of unexperienced users that are actually using a 64Bit firefox? You seem to believe, that the users are _expecting_ production quality builds. I mean: you don't offer FireFox 64Bit on any main download page, as far as I'm aware.

> It may be if the bad code in win64-only. The most recent instance of this
> was a bug that seems to be cause by win64 PGO that caused a performance
> improvement to be backed out, slowing things down on all other platforms
> too.

And I seem to remember there being a major crasher on 64-bits not too long
ago that also resulted from bad PGO...

> And obviously win64 PGO bugs in MSVC have no effect whatsoever on other
> platforms...

Subscribe to the MSKB RSS feed for Visual Studios, and one will see that
Microsoft releases hotfixes all the time for their build tools--both the
32-bit and 64-bit ones--to fix various issues of incorrect code generation,
so this isn't a problem that's specific to 64 bits. Weren't there 32-bit
PGO-related crashers a while back, too? In any case, why not just disable
PGO entirely on 64 to reduce the amount of work needed to sustain 64-bit
builds? Firefox is idling 99% of the time, anyway, so I'm not sure how much
PGO matters in the real world, outside of benchmarks.

Just my 2 cents but it seems to me this is the absolute wrong direction to be going... if anything you should be making a release version of the Win64 version... not stopping 64bit developer builds. I use the 64bit nightly build and it does not appear to be more buggy to me than the 32bit version, in fact I tend to have more problems with the 32bit version personally.

It should be pretty obvious from crash reports what version is being run... I mean it is plainly obvious when a crash has 64bit registers and addresses. If it is a report in the bug reporting system that is a problem, then that lies on the shoulders of the bug reporters... they should specify which version is being run... and this would also be a problem on Mac since they may not know which version they are running since it is a 32/64bit bundle.

I don't even understand how this came to be an issue that is being discussed. Push towards a 64bit release version not the other way around!

very strange to say all of this, yet people in the wider community are easily releasing 64 bit versions of firefox, waterfox being one of them. How about since you are turning off the 64 bit nightly, officially supporting and linking to waterfox. If it wasn't for waterfox i would simply walk away from firefox due to this very backwards decision in a time where all new computers being released are 64 bit. no wonder firefox has lost so many users to chrome when people like you treat the users like this, shame the wider community can't vote on this and tell you where to shove your idea

> 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

> 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

I have been using the mail/browser products from Netscape/Mozilla from day one and I have been a happy tester of the 64bit nightlies on both Win+linux from the very start. Since the OS world on desk-/laptops is moving to 64bit all over (all my win/linux machines are 64bit for years) I thought testing 64bit nightlies was a "natural thing" and paving the way for regular 64bit builds anytime soon. For quite some time, the nightly 64bit on Windows has been OK for everyday usage to me.

Though I strongly disagree I understand that rare resources are a good reason to make a decision. However, pressure does not turn any quick decision to cut off something automagically into a good decision. This one is a terribly bad one I see in line with the recent announcement to slow down / fade out Thunderbird development.

I accept that you have other priorities than I would like to see and you are primarily targeting an audience I am not part of anymore.

> 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
>

On Wed, Nov 21, 2012 at 8:19 AM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
>
> 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.

It's clear now that this decision has angered off many of our Nightly
users -- dozens have responded unhappily, and for every one that has
written there are probably many more that haven't. (A rule of thumb
from politics is that for every voter that writes a letter, there are
100 more that think the same thing; YMMV.)

These people are some of our most important users, because (a) they
provide early testing and feedback, and (b) they are likely to be
overly influential users, i.e. the kind that recommend to their
friends and familiy which browser they should use.

I understand the concerns about developer efforts. Can we please
re-enable these builds, stash them somewhere obscure so that no-one
will ever unintentionally stumble across them, and slap a giant
warning on them saying "no support, no promises, no nothing, use at
your own risk"?

That would consume negligible developer resources, but would give us a
chance to regain the goodwill that we're currently pissing away.

> It's clear now that this decision has angered off many of our
> Nightly users -- dozens have responded unhappily, and for every one
> that has written there are probably many more that haven't.

I don't think that's clear at all. On just about every issue, there's a
vocal faction who will complain. We can't run a project that's held
hostage by indecision and who-yells-the-loudest. But we _can_ ask our
technical leaders (like Benjamin) to gather info, weigh the factors, and
make the best decision they can.

> These people are some of our most important users [...] "no support,

> no promises, no nothing, use at your own risk"?

But then what's to be done when some bug inevitably breaks things for
"our most important users"? You can't have it free both ways.

In the end, the Nightly/Aurora/Beta channels are a mechanism for
ensuring that we ship high-quality software on the Release channel.
Until we have a firmer plan for shipping Win x64 builds -- which is a
separate discussion -- testing them isn't serving a purpose.

On 26/11/12 03:36, Justin Dolske wrote:
> I don't think that's clear at all. On just about every issue, there's a
> vocal faction who will complain.

Particularly if the issue makes it to Slashdot.

> We can't run a project that's held
> hostage by indecision and who-yells-the-loudest. But we _can_ ask our
> technical leaders (like Benjamin) to gather info, weigh the factors, and
> make the best decision they can.

Indeed. It's called "prioritization". In November 2012, 64-bit builds
are not a priority. For a start, they don't provide Firefox to anyone
who doesn't already have it. We are instead working on several things,
e.g. Firefox OS, ARMv6 Android - which do.

In June 2013, the picture may well be entirely different. Which is fine.
We can revisit the question when the landscape changes.

Also, regardless of the final decision, we need to at least communicate
some clear plans to the community. Explain why we had win64 nightlies
until now, why we have turned them off, and whether/when they will return.

> It's clear now that this decision has angered off many of our Nightly
> users -- dozens have responded unhappily, and for every one that has

> written there are probably many more that haven't. (A rule of thumb
> from politics is that for every voter that writes a letter, there are
> 100 more that think the same thing; YMMV.)
>
> These people are some of our most important users, because (a) they
> provide early testing and feedback, and (b) they are likely to be
> overly influential users, i.e. the kind that recommend to their
> friends and familiy which browser they should use.
>
> I understand the concerns about developer efforts. Can we please
> re-enable these builds, stash them somewhere obscure so that no-one
> will ever unintentionally stumble across them, and slap a giant

> warning on them saying "no support, no promises, no nothing, use at
> your own risk"?
>

> That would consume negligible developer resources, but would give us a
> chance to regain the goodwill that we're currently pissing away.
>
> Nick

> In June 2013, the picture may well be entirely different. Which is fine. We
> can revisit the question when the landscape changes.

By turning non-priority builds off in the mean time (as opposed to
keeping them in a holding pattern) we lose, as Nicholas said, the
goodwill of some of the people who’ve specifically sought out the
64-bit builds and potentially others who aren’t in that set of people
but think the move signals a direction they don’t like. Not all of
those people are going to come back if 64-bit Windows builds are
turned back on in June 2013.

Those people are part of the base that pro-Firefox word of mouth
builds upon. And that word of mouth has allowed Firefox to gain market
share with almost no traditional advertising and without becoming
installware bundled with Skype or Flash Player. And this isn’t just an
isolated one-time case of annoying the base. There have been multiple
occasions of trying the patience of the base since early 2011. While
keeping 64-bit builds parked at tier-2 probably wouldn’t have created
positive word of mouth, turning them off generates yet another round
of negative sentiment.

The build bot cost of 64-bit Windows builds could have been reduced by
turning off unit tests only and reducing the build frequency. The cost
on developer attention could have been reduced by tweaking Socorro to
discard or separate crash reports from 64-bit builds and by turning
off PGO.

As for refocusing the tester population to a configuration that gets
shipped, that sort of reasoning treats nightly testers as a commodity
for Mozilla to refocus instead of people who’ve specifically sought
out to run the kind of builds that are of interest to them. (Nightly
testing probably attracts the kind of users who have zillions of tabs
and can actually hit the virtual address space limit, so I think the
choice shouldn’t be written off as irrational even if 32-bit builds
outperforms 64-bit builds on benchmarks.) Also, people who test
non-shipping nightly configurations still contribute to testing
cross-platform behavior that gets shipped.

> By turning non-priority builds off in the mean time (as opposed to
>
> keeping them in a holding pattern) we lose, as Nicholas said, the
>
> goodwill of some of the people who’ve specifically sought out the
>
> 64-bit builds and potentially others who aren’t in that set of people
>
> but think the move signals a direction they don’t like. Not all of
>
> those people are going to come back if 64-bit Windows builds are
>
> turned back on in June 2013.
>
>
>
> Those people are part of the base that pro-Firefox word of mouth
>
> builds upon. And that word of mouth has allowed Firefox to gain market
>
> share with almost no traditional advertising and without becoming
>

> installware bundled with Skype or Flash Player. ...

>
> The build bot cost of 64-bit Windows builds could have been reduced by
>
> turning off unit tests only and reducing the build frequency. The cost
>
> on developer attention could have been reduced by tweaking Socorro to
>
> discard or separate crash reports from 64-bit builds and by turning
>
> off PGO.
>
>
>
> As for refocusing the tester population to a configuration that gets
>
> shipped, that sort of reasoning treats nightly testers as a commodity
>
> for Mozilla to refocus instead of people who’ve specifically sought
>
> out to run the kind of builds that are of interest to them. (Nightly
>
> testing probably attracts the kind of users who have zillions of tabs
>
> and can actually hit the virtual address space limit, so I think the
>
> choice shouldn’t be written off as irrational even if 32-bit builds
>
> outperforms 64-bit builds on benchmarks.) Also, people who test
>
> non-shipping nightly configurations still contribute to testing
>
> cross-platform behavior that gets shipped.
>
>
>
> --
>
> Henri Sivonen
>

I totally agree with Henri Sivonen, that it is a bad signal that people who want to actively support and enhance something by investing their time are turned away. Also you turn away the voluntary developer who wants to bring FF on the 64 Bit architecture.

I absoltuly disagree with the statment :

> We can't run a project that's held
> hostage by indecision and who-yells-the-loudest. But we _can_ ask our
> technical leaders (like Benjamin) to gather info, weigh the factors, and
> make the best decision they can.

Even if it comes under the cloak of prioritization, the reason why mozilla and firefox are one of the most successful open source projects is not that one leader decides and the common volunteer sheep follow.
I fully respect the professional opinion of Benjamin but I absolutely disagree with the direction that the decision should not be questioned until summer 2013 and that ever should not discuss this decision and turn away the volunteers that try to contribute in a specific field.

Am Montag, 26. November 2012 12:19:18 UTC+1 schrieb David Rajchenbach-Teller:
> I believe that Nicholas' remark makes sense.
>
> Also, regardless of the final decision, we need to at least communicate
> some clear plans to the community. Explain why we had win64 nightlies
> until now, why we have turned them off, and whether/when they will return.

It's easy to explain, Firefox Desktop is no longer the leading platform! Firefox OS and Firefox Android is the new leading platform.

I've been using firefox 64bit myself for about 1 year+
I use 64bit, because 32bit cannot readily handle the amount of windows+ tabs I use, and have open at all times (5 windows 72+ tabs) which is about 5-7 days at a time.

Only crashes I've had from 64bit is after about 5-7 days, it gets really sluggish and slowly unresponsive. 32Bit would do the same after about 1 day requiring a restart.

If the nightly builds are being stopped, I would rather "automatically" be moved to whatever the other current 64bit version is (some beta build somewhere?). Or I can just stay with my current 64bit nightly, and just never update it again. For me usability of the 64bit and all I use it for, is alot more important then having to constantly restart the browser because it cannot handle all that I go through on a daily basis.

3-6GB of ram usage won't kill me, its the nice thing about 64bit windows and 16GB ram, and I plan to get 32GB on my next PC upgrade.

> By turning non-priority builds off in the mean time (as opposed to
>
> keeping them in a holding pattern) we lose, as Nicholas said, the
>
> goodwill of some of the people who’ve specifically sought out the
>
> 64-bit builds and potentially others who aren’t in that set of people
>
> but think the move signals a direction they don’t like. Not all of
>
> those people are going to come back if 64-bit Windows builds are
>
> turned back on in June 2013.
>
>
>
> Those people are part of the base that pro-Firefox word of mouth
>
> builds upon. And that word of mouth has allowed Firefox to gain market
>
> share with almost no traditional advertising and without becoming
>

> installware bundled with Skype or Flash Player. ...

>
> The build bot cost of 64-bit Windows builds could have been reduced by
>
> turning off unit tests only and reducing the build frequency. The cost
>
> on developer attention could have been reduced by tweaking Socorro to
>
> discard or separate crash reports from 64-bit builds and by turning
>
> off PGO.
>
>
>
> As for refocusing the tester population to a configuration that gets
>
> shipped, that sort of reasoning treats nightly testers as a commodity
>
> for Mozilla to refocus instead of people who’ve specifically sought
>
> out to run the kind of builds that are of interest to them. (Nightly
>
> testing probably attracts the kind of users who have zillions of tabs
>
> and can actually hit the virtual address space limit, so I think the
>
> choice shouldn’t be written off as irrational even if 32-bit builds
>
> outperforms 64-bit builds on benchmarks.) Also, people who test
>
> non-shipping nightly configurations still contribute to testing
>
> cross-platform behavior that gets shipped.
>
>
>
> --
>
> Henri Sivonen
>

I'm no developer, but I want to say something here, and pardon me for being blunt and to the point.

The 64-bit Browser works, but honestly you guys at Mozilla don't have any level of priorities to getting any finalized code out. If you want developers for plugins and add-ons you have to give people a regular finalized release of code. No stable version = no developers, plain and simple.

HTML5 is coming soon enough that will make plugins like Java, Flash, Silverlight, etc. less than useful if even needed at all.

Plus, not only this but seriously, if you have a core project that is architecture independent, you should be worrying about which architecture reports come in from.

I still question why Linux has a working 64-bit release while Windows doesn't. That makes absolutely NO sense at all. If Linux can have a stable 64-bit release, so can Windows. Just Finalize Builds of the 64-bit Windows versions and release them out already! The 64-bit Linux browser did NOT have plugins right away when it was released, but it got them because finalized code was made available to developers to write plugins for.

Flash, Silverlight, and Java as well as several other independent plugins like PDF-XChange exist for 64-bit Firefox already and are more than enough to play all the multimedia content out there, so why the hold up?

On 26/11/12 11:29, Henri Sivonen wrote:
> As for refocusing the tester population to a configuration that gets
> shipped, that sort of reasoning treats nightly testers as a commodity
> for Mozilla to refocus instead of people who’ve specifically sought
> out to run the kind of builds that are of interest to them. (Nightly

I moved my elderly mother onto x64 nightly because her Laptop (it's one of those C50-based things) didn't have enough spare cycles for her to play her facebook games with 32 bit firefox.

x64 windows, 32 bit firefox, and 64 bit flash just made it impossible to play her terrible, brainrotting games... and it became my problem.

I switched her to nightly because it solved the problem - no 32 bit code running meant extra cpu cycles to go around, and I got to stay at home with my wifey and my 3 year old, playing video games and enjoying life.

disable x64 nightly builds... and... well I'll spend all my time over at mother's place, trying to explain that her computer is not broken, it's that this stupid witches brew is a waste of her time.

No mom, I didn't call you stup...
Well if I could get a 64-bit...
No mom, I'm not talking down at yo...
Oh god.
Kill me now.

> It's clear now that this decision has angered off many of our Nightly
> users -- dozens have responded unhappily, and for every one that has
> written there are probably many more that haven't. (A rule of thumb
> from politics is that for every voter that writes a letter, there are
> 100 more that think the same thing; YMMV.)
>
> These people are some of our most important users, because (a) they
> provide early testing and feedback, and (b) they are likely to be
> overly influential users, i.e. the kind that recommend to their
> friends and familiy which browser they should use.

On 11/26/2012 6:29 AM, Henri Sivonen wrote:
>
>
> As for refocusing the tester population to a configuration that gets
> shipped, that sort of reasoning treats nightly testers as a commodity
> for Mozilla to refocus instead of people who’ve specifically sought
> out to run the kind of builds that are of interest to them. (Nightly

> testing probably attracts the kind of users who have zillions of tabs
> and can actually hit the virtual address space limit, so I think the
> choice shouldn’t be written off as irrational even if 32-bit builds
> outperforms 64-bit builds on benchmarks.) Also, people who test
> non-shipping nightly configurations still contribute to testing
> cross-platform behavior that gets shipped.
>

Keeping the win64 builds on in their current state is *also* generating
negative sentiment. I deal with win64-specific crash and plugins bugs
several times a week, and when I mark them [win64] P5 and say that my
team is currently not prioritizing a bug, it makes people angry.

I believe that our nightly testers are volunteers who are trying to help
the Mozilla project. We should treat our nightly testers as a resource,
and to focus their participation and testing on the things which matter
most. Right now, running win64 builds doesn't help the project achieve
its important priorities. If most of our nightly users were using win32
instead, we would have much better population for crash statistics early
in the development cycle.

I believe that many of the existing win64 nightly users are not
attracted to 64-bit builds specifically, but because they ended up in a
directory such as
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-11-27-03-09-07-mozilla-central/and decided that since their computer was win64, they should download
that file instead of the other. Since we have the opportunity to direct
a significant portion of these testers to builds and testing which is
valuable, we should do so.

It is obviously hard to weight the net negative of people upset by a
decision to temporarily disable win64 builds versus the opportunity cost
of people who could be testing a build which is truly valuable; there is
obviously going to be judgement involved. But I don't think we should
extrapolate from a small set of users who are visibly upset to conclude
that we are angering our early-adopter/testing community in general.

In the future when we decide to prioritize win64, I expect that we could
easily get half of our nightly population to switch back either
automatically in the update system or with minimal prompting. We can
even use that event to invite new users into our nightly channel in a
way that is truly valuable to the project!

Sigh.. So it's coming down to zipping current nightly and using it later. 2gb is not enough for everybody :/

And what else to do? There is no other browser who can offer stable/good experience on 100+ tabs with Panorama and 2gb+ commit memory. Too hard to change your browser being hardcore fan for about 10 years :)

On 28/11/2012 04:05, nki...@gmail.com wrote:
> 2gb is not enough for everybody :/
> And what else to do? There is no other browser who can offer stable/good experience on 100+ tabs with Panorama and 2gb+ commit memory. Too hard to change your browser being hardcore fan for about 10 years :)

On a 64bit OS Firefox 32bit can use up to 4GB of memory that is plenty
for most use-cases. The 2GB story is just misinformation flying around.
-m

On 11/27/2012 10:05 PM, nki...@gmail.com wrote:
> Sigh.. So it's coming down to zipping current nightly and using it later. 2gb is not enough for everybody :/
>
> And what else to do? There is no other browser who can offer stable/good experience on 100+ tabs with Panorama and 2gb+ commit memory. Too hard to change your browser being hardcore fan for about 10 years :)
>

> Sigh.. So it's coming down to zipping current nightly and using it later. 2gb is not enough for everybody :/
>
> And what else to do? There is no other browser who can offer stable/good experience on 100+ tabs with Panorama and 2gb+ commit memory. Too hard to change your browser being hardcore fan for about 10 years :)
>

> If at least two other developers are capable of producing a stable and
> relatively bug free 64bit Firefox version it just amazes me why the

IIRC Pale Moon produced MSVC2010 binaries when Mozilla itself wasn't,
which is what lead to their claim of being faster. The reason Mozilla
wasn't doing it at the time was because there were several known bugs
caused by compiler issues. When they got fixed, we switched to MSVC2010
as well.

The same story applies to x64, except that it will actually get worse
for Pale Moon/Waterfox users if Mozilla stops fixing x64 issues. You
didn't see much x64 bugs in Waterfox because *MOZILLA* was fixing them.

It's not a coincidence that the call to stop the builds comes from the
people who're doing the latter.

> I deal with win64-specific crash and plugins bugs several times a week,
> and when I mark them [win64] P5 and say that my team is currently not
> prioritizing a bug, it makes people angry.

I have a feeling that they'll feel less angry if they knew that the
alternative is that there is no 64-bit build at all... As for me, I don't
mind the 64-bit bugs because whatever problems I have encountered are far
less than the out-of-memory problem that I run into with 32-bit builds on a
regular basis.

> I believe that our nightly testers are volunteers who are trying to help
> the Mozilla project. We should treat our nightly testers as a resource,
> and to focus their participation and testing on the things which matter
> most.

That's a bad assumption. I use Nightly 64 mostly for the "64", less for the
"Nightly", because of the massive memory requirements of my deeply-ingrained
usage patterns that I have no intention of ever changing (I browse the web
like a breadth-first search, not depth-first like most people, and thus I
always have tons of tabs open). So it's either this or e10s, and I suspect
that you'll agree that the former is a much easier solution? ;)

I'm sure that there are Nightly 64 users who use it for the wrong reasons
(because they want to test it or because they think that 64 is automatically
better than 32), and I have no qualms with trying to drive them away from
Nightly 64. But I'm not one of them, and judging from some of the replies in
this thread, I'm not the only person in this boat.

> But I don't think we should extrapolate from a small set of users who are
> visibly upset to conclude that we are angering our early-adopter/testing
> community in general.

Per what I said above, I'd like to add to that list the "power-user
community who use 64 bits out of address space necessity".

> Keeping the win64 builds on in their current state is *also* generating
> negative sentiment. I deal with win64-specific crash and plugins bugs
> several times a week, and when I mark them [win64] P5 and say that my
> team is currently not prioritizing a bug, it makes people angry.

I wonder if it might make sense to, in addition of removing the normal
64bit nightlies and auto-updating all their users to 32bit, enable 64bit
builds on some development branch, e.g. UX.
We don't get crashes from those development branches to show up in
crash-stats and those channels are not offered on nightly.mozilla.orglike 64bit nightlies were for a while. It's made pretty clear that
builds from those dev branches are highly experimental.
This would enable the small but vocal minority from here to get builds
that are capable of more than 4GB of RAM, would enable us to still find
out when through reports when a 64bit-spcific breakage/problem happens
so we can lazily resolve it (lazily because people were clearly pointed
to this being highly experimental) and it would give that dev branch a
few more testers (I suggested UX because the experiments there are
probably highly unrelated to 64bit-specific problems).

>> 2gb is not enough for everybody :/
>
> Please stop spreading the 2GB lie. It's been said multiple times in this
> thread that it's 4GB.

Okay, "4GB is not enough for everybody." ;) It doesn't matter that much if
it's 2GB, 4GB, or "somewhere between 3 and 4GB in practice"--the actual
location of this line is not as important as the fact that a line that is
plausibly reachable by (an admittedly small number of) users does exist and
that in the absence of e10s, a large address space is the only readily
viable solution.

How many tabs is tons? I have 546 tabs open at the moment on 32 bit Windows
7 Nightly. Of 2GB memory in use, 800MB is Firefox. Mind you Firefox has
been open for days - if I close it and reopen it will probably use 400MB.
Make sure you have the lazy opening of tabs turned on (that is only loaded
when they get focus) - which I understand is the default. It makes Firefox
around as fast starting up with 546 tabs as any of the other browsers
starting a fresh session.

(I counted tabs using the Tab hunter extension)

The point I am making is Firefox does pretty well on 32bit in memory use.

Someone else pointed out that FIrefox shows as one of the most crashing apps
on Windows 7 - could be true - I am betting its the Flash Player. Due to
the fast restart its not much of an issue. Much less bother than that other
app that crashes from time to time on Windows 7 (the app called Windows 7).

> How many tabs is tons? I have 546 tabs open at the moment on 32 bit
> Windows 7 Nightly. Of 2GB memory in use, 800MB is Firefox. Mind you
> Firefox has been open for days - if I close it and reopen it will probably
> use 400MB. Make sure you have the lazy opening of tabs turned on (that is
> only loaded when they get focus) - which I understand is the default. It
> makes Firefox around as fast starting up with 546 tabs as any of the other
> browsers starting a fresh session.

About 1000. ;) And yes, I do use (and love) the lazy open of tabs. It means
that after a fresh restart, my usage is well under 1GB. And if I don't do
very much, it likely remains under 2GB for days on end. But when I do use it
heavily, I've had it bloat up to 8GB after several days. All this depends on
specific usage habits, what kind of websites are visited, etc.

> Someone else pointed out that FIrefox shows as one of the most crashing
> apps on Windows 7 - could be true - I am betting its the Flash Player.
> Due to the fast restart its not much of an issue. Much less bother than
> that other app that crashes from time to time on Windows 7 (the app called
> Windows 7).

It would be best if you posted this in the other message thread, as this is
mostly unrelated to the win64 question... (BTW, plugins like Flash live in
their own container process whose untimely deaths do not affect Firefox).

I use Firefox/Nightly as it is. We use it for graphic works via php-Code. The code is optimized for Firefox. So I often go to the limits of a 32bit Firefox, I don't have with the 64bit Nightly. Therefore in my opinion there is no 2GB-lie. I only use 2 plugins: goo.gl and AdBlock +. Both are just working fine. The only thing that bothers me is to change the language to german. I often gets errors, if theres no actual xpi-file.

After the release of Firefox OS, when the Firefox developers will have more time, a windows Firefox 64 official release will attract millions of new users!

I saw in google trends that people are becoming more interested in 64 bit browsers, and they are about the same number with people interested in Firefox Android. Also Waterfox, which is a Firefox 64 build, is getting more and more interest.

Obviously this decision totally lacks the vision needed for the position which you
are in, the proper way to act would rather be to set out a migration path towards
64-bit and let the 32-bit version die out over the coming years. Virtually all
new PC's are currently 64-bit and as users broadband access gets faster and applications can get more complex the need for 64-bit will become increasingly
clear as web pages get rich content such as 3D and all features possible with HTML5. Instead of complaining about addon support, try to create incentives for
developers to go 64-bit, if you don't show a clear vision it's no wonder
developers will be hesitant to investing in 64-bit support, it's your task
to at least try to break through this chicken and egg issue.

There is no 32 bits cpus anymore. Why keep 32 bits code? This is not logical. Thank GOD for 64 bits GNU/linux making possible to be out of this madness. Hardware world goes always to the future and you guys are stuck in something from 10 years ago.

> > 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

On Saturday, November 17, 2012 2:12:13 AM UTC+8, 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.
>
>
>

> The Windows 64-bit builds are a constant source of misunderstanding and

> frustration ...

From the user's perspective FF32 is frustrating because it runs into memory problems when many (~150) or fewer memory heavy tabs are kept open. FF runs into a "wall of jelly" and does not update the screen any more, black areas of rectangular shape appear on screen. All the while >10GB RAM may be free - FF32 of course does not use it. Re-starting the browser helps only for a while. I watch the taskmanager - if the memory line does not increase the limit is reached - sooner or later FF will crash. FF32 does not warn the user either.

The 64bit Version does not have *this* persistent problem. So it is hard to understand, why developers work on "other things" than stability. If the focus of the mozilla team lay on 64bit the add-on-developers would soon notice and start porting addons to 64bit.

I used 64bit nightlies to overcome the memory issue and to speed development by reporting bugs - no future for that? :-(