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

Turning off win64 builds

6,560 views
Skip to first unread message

Benjamin Smedberg

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

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

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

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

--BDS

Please followup to mozilla.dev.apps.firefox

Andrew Joakimsen

unread,
Nov 16, 2012, 1:21:56 PM11/16/12
to dev-apps-firefox List
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.

Sent from my iPhone

On Nov 16, 2012, at 1:11 PM, Benjamin Smedberg <benj...@smedbergs.us> wrote:

> crash-stats

Benjamin Smedberg

unread,
Nov 16, 2012, 1:35:38 PM11/16/12
to Andrew Joakimsen, dev-apps-firefox List
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.

crash-stats is just a symptom of the problem.

--BDS

Ed Morley

unread,
Nov 16, 2012, 2:03:03 PM11/16/12
to
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.

For additional reasons, see the previous thread about this:
https://groups.google.com/d/topic/mozilla.dev.planning/Giij-AZfUAM/discussion

Ed

Robert Kaiser

unread,
Nov 17, 2012, 2:01:35 PM11/17/12
to
Andrew Joakimsen schrieb:
> 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.

Robert Kaiser

Omega X

unread,
Nov 17, 2012, 10:45:12 PM11/17/12
to
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.

--
==================================
~Omega X
MozillaZine Nightly Tester

Mr. T

unread,
Nov 18, 2012, 5:30:12 PM11/18/12
to dev-apps-firefox List, mozilla.dev.planning group
> 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.

Matthew Turnbull

unread,
Nov 18, 2012, 7:38:01 PM11/18/12
to dev-apps...@lists.mozilla.org
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.

http://forums.mozillazine.org/viewtopic.php?p=12283535#p12283535

If you don't understand the differences between x32 and x64, or why you
would choose one over the other for a given situation, then you have no
business making such claims.
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>

--
Bluefang-Logic Networks:

Scaled for your pleasure.

spec...@gmx.de

unread,
Nov 19, 2012, 6:27:47 AM11/19/12
to dev-apps...@lists.mozilla.org
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.
Message has been deleted

Benjamin Smedberg

unread,
Nov 19, 2012, 11:29:22 AM11/19/12
to Omega X, dev-apps...@lists.mozilla.org
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.

--BDS

Srap

unread,
Nov 19, 2012, 11:52:36 AM11/19/12
to Omega X, dev-apps...@lists.mozilla.org
2012. november 19., hétfő 17:29:42 UTC+1 időpontban Benjamin Smedberg a következőt írta:
> The only question to decide here is
>
> whether the existing 64-bit Windows nightlies provide any value 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.

Correct me if I am wrong on this.
Message has been deleted

michael....@gmail.com

unread,
Nov 19, 2012, 10:04:58 AM11/19/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List
I thought the purpose of the Mozilla project was to innovate and push the web forward, not conform and fall back.

Benjamin Smedberg

unread,
Nov 19, 2012, 12:36:29 PM11/19/12
to Srap, dev-apps...@lists.mozilla.org
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.

--BDS

Alex Jordan

unread,
Nov 19, 2012, 6:26:04 PM11/19/12
to Srap, dev-apps...@lists.mozilla.org, Omega X
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.)

Chris Peterson

unread,
Nov 19, 2012, 7:07:16 PM11/19/12
to
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.

chris

[1] https://code.google.com/p/chromium/issues/detail?id=8606
[2] https://code.google.com/p/chromium/issues/detail?id=18323
[3]
http://dev.opera.com/articles/view/64-bit-opera-and-out-of-process-plug-ins/

Makoto Kato

unread,
Nov 19, 2012, 9:05:54 PM11/19/12
to
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
>

-- Makoto

Wayne

unread,
Nov 19, 2012, 11:19:18 PM11/19/12
to
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

Video driver / graphics issues on 64bit systems ranks pretty high too, no?

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.

[1] "64bit" bugs with activity in past year http://tinyurl.com/cmjjpue


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

Also, bug 811051 doesn't identify the crashes/examples being implicated.
Is #2 FF19 crash an example?
https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A19.0a1&query_search=signature&query_type=contains&reason_type=contains&date=11%2F19%2F2012%2023%3A46%3A28&range_value=2&range_unit=days&hang_type=any&process_type=any&do_query=1&admin=1&signature=nsHttpConnection%3A%3ASetSecurityCallbacks%28nsIInterfaceRequestor*%29
- the bug report indicates fixed but doesn't indicate a specific
connection to 64bit.


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

chaosfre...@gmail.com

unread,
Nov 20, 2012, 12:08:10 AM11/20/12
to
Disable x64 Windows builds, I switch to Chrome.

Daniel Holbert

unread,
Nov 20, 2012, 2:09:44 AM11/20/12
to chaosfre...@gmail.com, dev-apps...@lists.mozilla.org
On 11/19/2012 09:08 PM, chaosfre...@gmail.com wrote:
> Disable x64 Windows builds, I switch to Chrome.

That won't help you much... Did you see Chris Peterson's email elsewhere
in this thread? Quoting him here:

On 11/19/2012 04:07 PM, Chris Peterson wrote:
> Google does not support 64-bit
> Chrome builds for Windows [1] or Mac OS X [2]
[...]
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.

spec...@gmx.de

unread,
Nov 20, 2012, 4:55:13 AM11/20/12
to
Am Dienstag, 20. November 2012 01:07:18 UTC+1 schrieb Chris Peterson:
> On 11/18/12 2:30 PM, Mr. T wrote:

>Opera has experimental
> 64-bit builds for Windows [3], but AFAIK they have not been updated
> since February.

With release of Opera 12, Opera support 64 bit builds, download the current Opera with 64 bit Windows and you get 64 bit Opera.

chaosfre...@gmail.com

unread,
Nov 20, 2012, 6:21:38 AM11/20/12
to
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.

Marco Bonardo

unread,
Nov 20, 2012, 9:03:38 AM11/20/12
to
On 20/11/2012 12:21, chaosfre...@gmail.com wrote:
> 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.

-m

spec...@gmx.de

unread,
Nov 20, 2012, 9:04:53 AM11/20/12
to
Am Dienstag, 20. November 2012 03:05:44 UTC+1 schrieb Makoto Kato:

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

- PDF-Xchange
- VLC-Player

Boris Zbarsky

unread,
Nov 20, 2012, 11:02:26 AM11/20/12
to
On 11/20/12 6:21 AM, chaosfre...@gmail.com wrote:
> Now Mozilla is backing away from what it was?

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.

-Boris

superg...@gmail.com

unread,
Nov 20, 2012, 12:13:29 PM11/20/12
to
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)

Srap

unread,
Nov 20, 2012, 1:24:22 PM11/20/12
to
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.

Robert Kaiser

unread,
Nov 20, 2012, 4:21:34 PM11/20/12
to
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.

Robert Kaiser

Robert Kaiser

unread,
Nov 20, 2012, 4:39:03 PM11/20/12
to
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.

Robert Kaiser

Brian Smith

unread,
Nov 20, 2012, 7:05:51 PM11/20/12
to spec...@gmx.de, dev-apps...@lists.mozilla.org
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.

Cheers,
Brian

emanuel....@gmail.com

unread,
Nov 21, 2012, 8:12:10 AM11/21/12
to
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?

Wayne

unread,
Nov 21, 2012, 10:57:06 AM11/21/12
to
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.

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.

Benjamin Smedberg

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

--BDS

fuka...@gmail.com

unread,
Nov 21, 2012, 2:16:40 PM11/21/12
to dev-apps-firefox List, mozilla.dev.planning group
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?

alex_mayorga

unread,
Nov 21, 2012, 4:04:07 PM11/21/12
to dev-apps-firefox List, mozilla.dev.planning group
I guess you should also WONTFIX https://bugzilla.mozilla.org/show_bug.cgi?id=471090 then.

Anecdotally, I've been running Nightly 64-bit with no major issues for well over a year now.

The only time it got "crashy" was when 32-bit itself was.

Alex

alex_mayorga

unread,
Nov 21, 2012, 4:04:07 PM11/21/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List
On Wednesday, November 21, 2012 10:19:43 AM UTC-6, Benjamin Smedberg wrote:

jes...@staunhansen.dk

unread,
Nov 21, 2012, 5:34:13 PM11/21/12
to dev-apps-firefox List, mozilla.dev.planning group
I'd be sad to see it disabled entirely. I believe that the x64 builds reveal potential issues in the x86 builds that wouldn't trigger crashes immediately but might in the future.

jes...@staunhansen.dk

unread,
Nov 21, 2012, 5:34:13 PM11/21/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

Robert Kaiser

unread,
Nov 21, 2012, 6:36:15 PM11/21/12
to
Wayne schrieb:
> 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.

In any case, the decision was made, so let's go by that.

Robert Kaiser

yuhong...@hotmail.com

unread,
Nov 22, 2012, 1:37:42 AM11/22/12
to
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.

Yuhong Bao

unread,
Nov 22, 2012, 1:57:27 AM11/22/12
to
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

AFAIK, IE10 basically automatically determines whether 32-bit or 64-
bit is appropriate for each process when it creates them. For example,
Metro IE is entirely 64-bit because only a limited whitelist of plug-
ins are supported.
http://blogs.msdn.com/b/ieinternals/archive/2012/03/23/understanding-ie10-enhanced-protected-mode-network-security-addons-cookies-metro-desktop.aspx

steven...@gmail.com

unread,
Nov 22, 2012, 2:40:22 AM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group
On Wednesday, November 21, 2012 10:19:43 AM UTC-6, Benjamin Smedberg wrote:
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.

kaneide...@gmail.com

unread,
Nov 22, 2012, 6:30:37 AM11/22/12
to
Well, decisions can be rethought and changed!

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.

I hope you keep those x64 builds.

Best,
Daniel

ana...@gmail.com

unread,
Nov 22, 2012, 8:30:45 AM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group
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

Then finish implementing Bug#595053: https://bugzilla.mozilla.org/show_bug.cgi?id=595053

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

Armen Zambrano G.

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

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

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

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

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

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

kl...@code.kliu.org

unread,
Nov 22, 2012, 9:24:31 AM11/22/12
to dev-apps...@lists.mozilla.org
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.

kl...@code.kliu.org

unread,
Nov 22, 2012, 9:30:11 AM11/22/12
to
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.

collyer...@gmail.com

unread,
Nov 22, 2012, 9:49:37 AM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group
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.
Aww, come on, even the ugly IE6 have a 64 bits version. Don't say that Firefox and Thunderbird can't have 64 bits versions too. :(
Firefox owned by IE6. :'(

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

henk...@gmail.com

unread,
Nov 22, 2012, 9:59:28 AM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group
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.
>
>
>
> --BDS
>
>
>
> Please followup to mozilla.dev.apps.firefox

How about you fix the problems instead?

32-bit needs to follow the path of other dinosaurs, go extinct.

Internet Exploder here i come... *sigh*.

fuka...@gmail.com

unread,
Nov 21, 2012, 2:16:40 PM11/21/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

steven...@gmail.com

unread,
Nov 22, 2012, 2:40:22 AM11/22/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List
On Wednesday, November 21, 2012 10:19:43 AM UTC-6, Benjamin Smedberg wrote:

ana...@gmail.com

unread,
Nov 22, 2012, 8:30:45 AM11/22/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List
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

Then finish implementing Bug#595053: https://bugzilla.mozilla.org/show_bug.cgi?id=595053

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

kl...@code.kliu.org

unread,
Nov 22, 2012, 9:24:31 AM11/22/12
to mozilla.dev....@googlegroups.com, dev-apps...@lists.mozilla.org

collyer...@gmail.com

unread,
Nov 22, 2012, 9:49:37 AM11/22/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List
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.
Aww, come on, even the ugly IE6 have a 64 bits version. Don't say that Firefox and Thunderbird can't have 64 bits versions too. :(
Firefox owned by IE6. :'(

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

henk...@gmail.com

unread,
Nov 22, 2012, 9:59:28 AM11/22/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List
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.
>
>
>

Gregory Szorc

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

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

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

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

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

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

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

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

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

Gregory

d1c...@googlemail.com

unread,
Nov 22, 2012, 4:23:06 PM11/22/12
to dev-apps-firefox List, mozilla.dev.planning group
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

Kai Liu

unread,
Nov 22, 2012, 5:17:02 PM11/22/12
to
> 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.

// KL

Ehsan Akhgari

unread,
Nov 22, 2012, 5:43:18 PM11/22/12
to Kai Liu, dev-apps...@lists.mozilla.org
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.

Cheers,
Ehsan

Benjamin Smedberg

unread,
Nov 22, 2012, 9:15:21 PM11/22/12
to Armen Zambrano G., dev-apps...@lists.mozilla.org
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.

--BDS

Robert Kaiser

unread,
Nov 22, 2012, 10:43:39 PM11/22/12
to
kaneide...@gmail.com schrieb:
> 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.

Robert Kaiser

Robert Kaiser

unread,
Nov 22, 2012, 10:45:32 PM11/22/12
to
yuhong...@hotmail.com schrieb:
> 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.

Robert Kaiser

smo...@gmail.com

unread,
Nov 23, 2012, 3:10:27 AM11/23/12
to dev-apps-firefox List, mozilla.dev.planning group
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.

david....@gmail.com

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

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

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


Sent from my BlackBerry® wireless device

-----Original Message-----
From: dcl...@gmail.com
Sender: dev-planning-bounces+david.weiruk=gmai...@lists.mozilla.orgDate: Fri, 23 Nov 2012 00:48:05
To: <dev-pl...@lists.mozilla.org>
Cc: mozilla.dev.planning group<dev-pl...@lists.mozilla.org>; dev-apps-firefox List<dev-apps...@lists.mozilla.org>
Subject: Re: Turning off win64 builds

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

_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning

John Bird

unread,
Nov 23, 2012, 6:56:45 AM11/23/12
to dev-apps...@lists.mozilla.org
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.

John Bird

mitchm...@gmail.com

unread,
Nov 23, 2012, 7:32:04 AM11/23/12
to
On Tuesday, November 20, 2012 1:07:18 AM UTC+1, Chris Peterson wrote:

> Opera has experimental 64-bit builds for Windows [3], but AFAIK they have not been updated
> since February.
> [3] http://dev.opera.com/articles/view/64-bit-opera-and-out-of-process-plug-ins/

You should be looking at the http://my.opera.com/desktopteam builds for regular snapshots or ftp://ftp.opera.com/pub/opera/win/1211/en/ for the official (english) release, which includes x64 builds. Although we do support x64 and even handle 32-bit plugins (as OOP), they do receive less attention than the 32-bit builds.

Boris Zbarsky

unread,
Nov 23, 2012, 9:37:29 AM11/23/12
to
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...

-Boris

sven.k...@gmail.com

unread,
Nov 23, 2012, 9:39:48 AM11/23/12
to dev-apps-firefox List, mozilla.dev.planning group
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.

Kai Liu

unread,
Nov 23, 2012, 10:29:49 AM11/23/12
to
> Companies like Adobe can further delay any effort in making a 64Bit Flash
> plug-in

64-bit Flash plugins have been officially released and supported (i.e., no
longer experimental) for quite some time now.

> or a 64Bit adobe reader plugin.

Firefox has built-in PDF support...

> Also, what happened to the plugin-container concept? Shouldn't you be able
> to run 32Bit plugin in an external process?

That's a mess to implement. Long story short, it requires that 64-bit
versions of Firefox bundle both 32-bit and 64-bit Gecko libraries, which
dramatically increases size and is just plain kludgy.

In any case, since the one plugin that most people use is Flash and Adobe
officially has and supports a 64-bit version, plugins really have not been a
major issue--at least, not for me.

// KL

Kai Liu

unread,
Nov 23, 2012, 10:45:06 AM11/23/12
to
> 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.

// KL

os2...@gmail.com

unread,
Nov 23, 2012, 3:04:42 PM11/23/12
to dev-apps-firefox List, mozilla.dev.planning group
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!

Brian

alienw...@gmail.com

unread,
Nov 23, 2012, 3:19:45 PM11/23/12
to dev-apps-firefox List, mozilla.dev.planning group
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

d1c...@googlemail.com

unread,
Nov 22, 2012, 4:23:06 PM11/22/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List
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

smo...@gmail.com

unread,
Nov 23, 2012, 3:10:27 AM11/23/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

sven.k...@gmail.com

unread,
Nov 23, 2012, 9:39:48 AM11/23/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

os2...@gmail.com

unread,
Nov 23, 2012, 3:04:42 PM11/23/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

alienw...@gmail.com

unread,
Nov 23, 2012, 3:19:45 PM11/23/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

gerd.na...@gmail.com

unread,
Nov 24, 2012, 3:40:57 AM11/24/12
to dev-apps-firefox List, mozilla.dev.planning group
Am Freitag, 16. November 2012 19:12:13 UTC+1 schrieb Benjamin Smedberg:
> 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.

Gerd

gerd.na...@gmail.com

unread,
Nov 24, 2012, 3:40:57 AM11/24/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

dokt...@yandex.ru

unread,
Nov 25, 2012, 4:51:38 AM11/25/12
to dev-apps-firefox List, mozilla.dev.planning group
суббота, 17 ноября 2012 г., 0:12:13 UTC+6 пользователь 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

I like firefox 64 bit, all stable work browser!

Nicholas Nethercote

unread,
Nov 25, 2012, 5:21:16 PM11/25/12
to dev-apps-firefox List, dev-platform
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.

Nick

Justin Dolske

unread,
Nov 25, 2012, 10:36:25 PM11/25/12
to
On 11/25/12 2:21 PM, Nicholas Nethercote wrote:

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

Justin

dokt...@yandex.ru

unread,
Nov 25, 2012, 4:51:38 AM11/25/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

Gervase Markham

unread,
Nov 26, 2012, 4:18:50 AM11/26/12
to Justin Dolske
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.

Gerv


David Rajchenbach-Teller

unread,
Nov 26, 2012, 6:18:47 AM11/26/12
to Nicholas Nethercote, dev-platform, dev-apps-firefox List
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.

Cheers,
David

On 11/25/12 11:21 PM, Nicholas Nethercote wrote:
> 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.
>
> Nick
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

signature.asc

Henri Sivonen

unread,
Nov 26, 2012, 6:29:15 AM11/26/12
to dev-apps...@lists.mozilla.org
On Mon, Nov 26, 2012 at 11:18 AM, Gervase Markham <ge...@mozilla.org> wrote:
> Indeed. It's called "prioritization". In November 2012, 64-bit builds are
> not a priority.
...
> 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.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

lukas....@gmail.com

unread,
Nov 26, 2012, 8:00:11 AM11/26/12
to dev-apps...@lists.mozilla.org
On Monday, November 26, 2012 12:29:22 PM UTC+1, Henri Sivonen wrote:

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

Cheers Lukas

--
Lukas Ramach

spec...@gmx.de

unread,
Nov 26, 2012, 8:20:28 AM11/26/12
to Nicholas Nethercote, dev-platform, dev-apps-firefox List
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.

Mark

unread,
Nov 26, 2012, 10:46:19 AM11/26/12
to dev-apps-firefox List, mozilla.dev.planning group
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.

lukas....@gmail.com

unread,
Nov 26, 2012, 8:00:11 AM11/26/12
to mozilla.dev....@googlegroups.com, dev-apps...@lists.mozilla.org
On Monday, November 26, 2012 12:29:22 PM UTC+1, Henri Sivonen wrote:

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

Mark

unread,
Nov 26, 2012, 10:46:19 AM11/26/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

maduinth...@gmail.com

unread,
Nov 26, 2012, 11:45:14 PM11/26/12
to dev-apps-firefox List, mozilla.dev.planning group
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?

Gervase Markham

unread,
Nov 27, 2012, 8:10:09 AM11/27/12
to Henri Sivonen
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

Now that is a reasonable point indeed.

Gerv

drwa...@evilinc.org

unread,
Nov 27, 2012, 11:06:22 AM11/27/12
to dev-apps-firefox List, mozilla.dev.planning group
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.

maduinth...@gmail.com

unread,
Nov 26, 2012, 11:45:14 PM11/26/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

drwa...@evilinc.org

unread,
Nov 27, 2012, 11:06:22 AM11/27/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

Benjamin Smedberg

unread,
Nov 27, 2012, 12:29:52 PM11/27/12
to dev-apps...@lists.mozilla.org
On 11/25/2012 5:21 PM, Nicholas Nethercote wrote:

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

--BDS

Arjan de Groot

unread,
Nov 27, 2012, 7:55:19 PM11/27/12
to
In <a000699c-48be-46f9...@googlegroups.com>,
maduinth...@gmail.com wrote:

>I still question why Linux has a working 64-bit release while Windows doesn't.
>That makes asolutely NO sense at all. If Linux can have a stable 64-bit release,
>so can Windows.

I'm using the 64bit version of Pale Moon and have no stability issues
whatsoever. And most plug-ins work just fine.

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
Mozilla development team itself can't do the same.

Anyway, if they want to shelve 64bit Firefox, ist's just their loss.
Use one of the browsers I mentioned instead. End of discussion.


Arjan

nki...@gmail.com

unread,
Nov 27, 2012, 10:05:01 PM11/27/12
to dev-apps-firefox List, mozilla.dev.planning group
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 :)
It is loading more messages.
0 new messages