
Firefox Developer Edition 38: 64-bits and more - gulbrandr
https://hacks.mozilla.org/2015/03/firefox-developer-edition-38-64-bits-and-more/
======
thristian
From the changelog:

> _autocomplete=off is no longer supported for username /password fields_

As far as I can recall, autocomplete=off was originally added specifically for
username and password fields, so somebody who nicked your laptop couldn't go
to your bank's website and have your username and password filled in.

As a power user I find autocomplete=off pretty annoying, but I've got ways to
work around it. I'm very curious what the rationale for this change is.

~~~
openjck
Lots of great discussion in the bug:

[https://bugzilla.mozilla.org/show_bug.cgi?id=956906](https://bugzilla.mozilla.org/show_bug.cgi?id=956906)

~~~
ploxiln
quote near end for the many people who won't read the thread:

    
    
        - This change makes it so that `autocomplete=off` does not stop the Password Manager from working. Normal form autofill can be disabled as usual.
        - The password manager *always* prompts if it wants to save a password. Passwords are not saved without permission from the user.
        - We are the third browser to implement this change, after IE and Chrome.
    

More clarification: password type input elements already never
autofill/autocomplete like other input elements do. autocomplete=off on
password type input elements just makes password managers not work (until this
change). Other input elements still honor autocomplete=off.

------
nnethercote
64-bit Windows builds, finally! This is great news. The rate of (virtual) OOM
crashes on Windows is pretty high because a 32-bit address space just isn't
enough for many workloads these days, and 64-bit builds solves that problem
definitely.

~~~
nextw33k
What? You are using more than 3.5GB of memory for your browser? I consider
myself a heavy user with 20-30 tabs open at any one time. I used to have a 2GB
memory usage with Adblock Plus and since switching to uBlock it averages 0.6GB
of RAM.

64bit will open more address space but it has proven in the past to slow the
browser down, the wider memory pointer size has a detrimental effect, Waterfox
is Firefox recompiled as 64bit and other compiler optimisations:
[http://www.networkworld.com/article/2185649/applications/fas...](http://www.networkworld.com/article/2185649/applications/fast-
firefox-faceoff--nightly-vs--pale-moon-vs--waterfox.html)

Not everything should be 64bit.

~~~
tyrfing
Yeah, I regularly hit 3gb+ even with uBlock. Counting, I have about 30 loaded
tabs right now (it's usually more like 100+ when I'm in the middle of doing
something), a few hundred unloaded, and 1800 MB RAM used. The tabs tend to
pile up when the browser eventually crashes...

This is with tree style tabs, which makes browsing so much more efficient for
me that Firefox is the only viable option.

------
bhouston
This is much needed for us at [http://Clara.io](http://Clara.io). We have for
the last 8 months been detecting when users who are using 32 bit desktop
browsers and have been putting up in-app warnings directing people to upgrade
to 64 bit versions.

Our forum post about the issue:

[http://forum.clara.io/t/information-on-64-bit-web-
browsers/9...](http://forum.clara.io/t/information-on-64-bit-web-browsers/979)

~~~
voltagex_
Do you have any stats on people who went away and installed a 64 bit browser?
clara.io's audience would be highly technical but I don't think you'd get away
with asking many people to install a new browser these days.

~~~
bhouston
We don't force them. We just recommend it for best experiences. It really does
make a difference.

We have google analytics but I am unsure if it tracks this automatically. We
do not manually track it I believe.

------
angersock
Nifty, but unfortunately we're still kinda limited to 32-bit addressing in
typed arrays. It'd be nice if JS had an actual integer type that went up to 64
bits.

~~~
azakai
32-bit is enough for a 4GB typed array, which doesn't seem too bad. I imagine
eventually it will be limiting, but not in the near future.

~~~
AceJohnny2
32-bits should be enough for everyone!

Sorry, I couldn't help myself ;) (and I know your "not in the near future"
makes the comparison incorrect anyhow)

~~~
Dylan16807
Thing is it's easy to need more than XX bits of stuff _total_ , it's a lot
rarer to want that in a single array in a high level language.

------
greenyoda
64-bit Windows builds of Firefox have been available for quite a while from
the Waterfox Project:

[https://www.waterfoxproject.org](https://www.waterfoxproject.org)

~~~
m3Lith
On the same note, it's worth mentioning Palemoon:
[http://www.palemoon.org/](http://www.palemoon.org/)

~~~
mp3geek
No one should use Pale moon, its just a fork of an older Firefox build.

------
mikko-apo
Chrome displays if the browser is 64bit in its about box, but for Firefox that
information is a bit harder to find out.

It's in about:buildconfig

------
wluu
From the comments, if you've got the 32bit version installed and want to
install the 64bit version (basically, it's not an update from one to the
other):

– Uninstall Win32 – Don’t remove your profile – Install Win64 (it’s a full
installer vs. a update)

------
ilaksh
I just want a browser that runs on Android with developer tools built in.

------
geeknik
Been using 64 bit Nightly builds (from Mozilla) for years. Not sure why this
is news.

~~~
dblohm7
Win64 builds have not been available in channels beyond Nightly until now.
That's why it is news.

------
andor
_If you haven’t downloaded the Developer Edition browser yet, it’s a fine time
to give it a try. Here’s why:_

Aha, so where can I try that Unreal Engine 4 demo myself?

------
ChuckMcM
Wow, that is pretty cool. At what point is a browser indistinguishable from an
emulated virtual computer?

~~~
sliverstorm
I'm still rather incredulous about the whole idea. I think to myself, if this
is the best way to do things, we must be missing something.

Though, I can't put my finger on why JVM seems reasonable while BrowserVM
doesn't.

~~~
TheDong
I think it's a matter of design. The Smalltalk integrated environment feels
completely right and was designed wonderfully with that intent in mind.

The JVM, likewise, has had a consistent and clear scope throughout.

Browsers are still not fully scoped out. From year to year, it varies what
webapps can do and what the norm is. Furthermore, it was not originally
designed with this usecase in mind. All those contribute to it feeling a lot
more awkward for this purpose than other, better designed, solutions.

Also, JVM/Pharo have significantly smaller scopes which helps.

------
yuhong
BTW, fixing open source JITs to support Windows x64 SEH properly is on my
wishlist for MS Open Tech.

------
frozenport
Was Firefox for Linux x64?

~~~
cesarb
Firefox has been available both as 32-bit and 64-bit on Linux for a long time.

Quoting myself
([https://news.ycombinator.com/item?id=8629233](https://news.ycombinator.com/item?id=8629233)):

\----

From what I have read, for software which wasn't originally developed for
Windows, especially if the code base is old enough, porting to 64-bit is
harder on Windows than on other systems.

The problem is that, while the Unix-based world went the LP64 way (int is
32-bit, long and pointers are 64-bit), Windows went the LLP64 way (int and
long are 32-bit, pointers are 64-bit). A lot of Unix programmers tended to
behave as if "long" was the largest native type ("long long" on 32-bit uses a
pair of registers). They have to scrub their whole code base for things like
assuming an object's size or array index will always fit on a "long".

\----

For Firefox, there's the additional problem of plugins. For a long time,
plugins on Windows have been 32-bit, and also for a long time, plugins for
Firefox on Windows (and other operating systems) were in-process, so it wasn't
possible to use a 32-bit plugin with a 64-bit browser.

Nowadays, not only can Firefox use a separate process for plugins, but also
the whole idea of browser plugins seems to be dying, so it's less of a
problem.

~~~
jheriko
the whole LP64 vs LLP64 'issue' is a massive red herring.

even in the most despicable code bases this is relatively quick and easy to
'fix', its just one of those things that on the face of it looks like a lot of
work, and is genuinely a brainless chore of find and replace with care.

its worth doing right anyway for plenty of reasons beyond portability, like
readability and maintainability.

using long on its own imo is a code smell. except for android (and maybe
linux, i can't remember otoh) long long is 64-bit and int is 32. but more
generally you can macro it away or use some standard size type header and do
the replacements to fix it.

the real problems i've seen with 64-bit portability are from bad serialisation
code, where struct padding breaks things, and hacks that rely on pointer casts
to ints etc. those are less easy because you can't find/replace them and so it
requires thought, not just care, to remove those issues safely.

------
Animats
Now, there's no limit to how much memory the browser can consume.

I hope this doesn't turn into a license to bloat.

------
cabirum
2 years 3 mons 11 days

[http://thenextweb.com/apps/2012/11/22/mozilla-quietly-
kills-...](http://thenextweb.com/apps/2012/11/22/mozilla-quietly-kills-
firefox-64-bit-for-windows-despite-an-alleged-50-of-testers-using-it/)

~~~
Dylan16807
[http://thenextweb.com/apps/2012/12/22/mozilla-backpedals-
on-...](http://thenextweb.com/apps/2012/12/22/mozilla-backpedals-on-
firefox-64-bit-for-windows-will-keep-nightly-builds-coming-after-all/)

Didn't happen. And support and stability has been growing.

