Firefox Developer Edition 38: 64-bits and more | Hacker News Reader

Firefox Developer Edition 38: 64-bits and more

hacks.mozilla.org

184 pointsgulbrandr61 comments

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.

Lots of great discussion in the bug:

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

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.

Lots of great discussion, but also lots of exasperating third-party comments.

While reading some of them I wanted to shake the authors and scream: "A website can't stop a user from saving a password! All you're doing is making them save it on a Post-It instead of in their password manager!"

for backend admin, when creating usernames and passwords for new users, you dont want those saved in your own browser.

pretty much the only use-case i've run into and can think of.

I've worked on use cases in both work and home environments.

Remember, a few years ago, not everyone had their own computer. For large chunks of the world (demographically and geographically), this is still the case.

Shared computer? You want to be applying autocomplete=off to sensitive fields. It's no guarantee, but it's one layer, assuming other layers (e.g. preventing keyloggers) are being maintained.

Only, I guess, you won't have this option, any longer.

At one point, I had to get one of my banks (big, "evil", you've heard of them) to apply it to their login web page. And I worked for another very big corporation that had at least in some people some pretty clueful in house developers. We applied it, as well. There were, and are, valid use cases. The setting alone won't save you, but it's one piece of a broader approach.

P.S. Oh yeah, and I seem to recall nudging a domain name registrar to apply it to the credit card number field on their payments page.

Browsers already automatically disable auto-complete from form history for "password" type input elements, this "autocomplete=off" would additionally prevente password managers from working. So that's what this change does: password managers will work, but password input fields still don't actually auto-complete from form history.

You should still be able to use autocomplete=off for non-password fields, like credit card.

Thank you for the clarification. I should have read through everything.

Doesn't private tabs solve that?

Lastpass saves me hours every week with their Auto Login and Form Fill features. If they are to be believed, all your stuff is encrypted on their servers. If you lose your master password, your screwed, so I don't think someone like the NSA or a hacker can get access to my login data.

The only way you can recover a lastpass account is if you do it from a computer that was already authenticated with lastpass in the near past.

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.

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

Not everything should be 64bit.

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.

Just open a few dozen tabs with high resolution images and 4 Gigs is gone quickly. It can come as surprise, I was also surprised when that happened first time. Luckily I was using 64 bit version but serious swapping started to lag my system.

I've been using 64bit version since 2006 on Linux. But if I don't remember wrong IE has been available as 64 bit version much longer. Xp 64 and 2003 Server used to use 64 bit IE6.

This is much needed for us at 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...

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.

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.

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.

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.

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)

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.

32-bit CPUs lasted for several decades in desktop computers, and I don't see it going away anytime soon. Personally, I think a lot of what average users are using computers for at the moment wouldn't need anything more than that. In most cases, 4GB is still a lot of memory... but it's easy to waste.

I mean, the super gnarly thing here is eventually emulating an MMU in JS, right?

Like, this almost gets us back to the nastiness of segmented memory models--you end up having the 32-bit addressable typed array as the "physical" memory, and then has the VMMU (virtual memory-management unit?) handle mapping from a virtual address (maybe a string?) to one of the physical addresses, and handling pagefaults.

Actually, that sounds kind of sexy, if anyone wants to bullshit on a PoC hack, shoot me an email.

Reminds me of this talk by Gary Bernhardt: https://www.destroyallsoftware.com/talks/the-birth-and-death...

I'm not sure what the typed array limitations are, but Javascript numbers are able to exactly represent integers up to 2^53 - 1, which is quite a bit more than 32 bits.

I think 64 bit integers in Typed Arrays are harder to implement than the other typed arrays already in Javascript. The highest integer you can safely work with in Javascript is 32 bits (using the ( number | 0 ) trick ) and so I wouldn't think it's just a coincidence that there isn't 64 bit integer arrays.

I hold out hope for ES7 or ES8 to have them though - especially when SIMD.js comes about.

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

https://www.waterfoxproject.org

These are the first official Firefox builds from Mozilla other than Nightlies. Before this, Mozilla didn't feel the 64-bit code was stable enough. Waterfox took the existing code and compiled it for 64-bit, but all the existing issues and bugs were present.

Holy crap, this is so much faster than Firefox. Lifesaver. Thanks!

You're similar versions with the same profile or both blank profiles? How much faster, how can you tell?

Same versions, same profiles, same # of bookmarks (hundreds), same # of plugins (adblock, ghostery, a few others).

Pages render a lot snappier and there's no scrolling lag in Waterfox vs Firefox. This is great.

On the same note, it's worth mentioning Palemoon: http://www.palemoon.org/

No, it's not.

https://news.ycombinator.com/item?id=8683630

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

And also from the Cyberfox project:

https://8pecxstudios.com/

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

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)

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

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

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

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?

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

That's a pretty interesting way to think of it. The only other platforms (AFAIK) that come close would be the JVM and Mono/CLR.

But the browser is more like a user-facing, interactive JVM/etc.

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.

Because tying your VM to a single application and it's user interface library (DOM/css, in this case) doesn't feel right?

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.

Sounds like FirefoxOS.

When you can run assembly on it, unless of course you are emulating a computer without assembly...

Does asm.js count? :-)

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

Was Firefox for Linux x64?

Seems to be 64 bit on Ubuntu 14.10

$ readelf -h /usr/lib/firefox/firefox

ELF Header:

  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 

  Class:                             ELF64

  Data:                              2's complement, little

endian

  Version:                           1 (current)

  OS/ABI:                            UNIX - System V

  ABI Version:                       0

  Type:                              DYN (Shared object

file)

  Machine:                           Advanced Micro Devices X86-64

Or just use file:

file /usr/lib/firefox/firefox

/usr/lib/firefox/firefox: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=16336605009f841acd45261f5f904be8509cfe21, stripped

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

----

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.

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.

The JIT needed some fixing to work correctly with SEH on Win64.

I use it for years on Linux already. I didn't even know on Windows Firefox wasn't 64 bit yet.

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

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

2 years 3 mons 11 days

http://thenextweb.com/apps/2012/11/22/mozilla-quietly-kills-...

http://thenextweb.com/apps/2012/12/22/mozilla-backpedals-on-...

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

Reply on news.ycombinator.com