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