i just want to say, Firefox is seriously fast now, while Chrome continues to get slower [1].
my 10M datapoint uPlot benchmark runs in half the time, for both pure js (fake data gen) and canvas workloads (chart rendering). check out the console in [2].
however, i'm still waiting for the performance assessment in devtools to improve so i can get an easy summary as i can in Chrome.
also, better default form input styling would be nice. it's so...Windows 98....but i'm on Windows 10. :\
> also, better default form input styling would be nice. it's so...Windows 98....but i'm on Windows 10. :\
Google and Microsoft seem to agree with you, but I totally don't get it!
If the website doesn't specify a style, my browser should fall back to a design that matches my OS, not whatever the browser developer thought was pretty!
And if Windows is coming back and telling the browser to use Windows 98 styled buttons, Microsoft should fix Windows!
> The underlying problem is Windows suggesting Windows 98 styled buttons
I'm almost positive that Firefox doesn't use OS-native controls; they've specifically styled their controls to look the way they do, so yes, this is a Firefox problem, not a Windows problem.
Really? The reason I assumed otherwise is that, the buttons on Mac look like Mac buttons to me. And furthermore, the buttons on my Mavericks Mac (pre Apple's flat redesign) look different than the ones on my High Sierra Mac.
I think it's an imitation. They're not stock UI elements. For example, on my Mojave system, if I just make an HTML button, I can see it doesn't respect the systemwide dark setting, the highlight color looks slightly darker than a normal light-theme button and it doesn't invert the text color when highlighted.
Wow this is interesting! Does that means technically we could have any OSX app compiled for windows while still retaining OSX-like appearance? Did Apple ever released this AppKit windows port for others to use? Does apple still maintaining the port for MacOS as well or did it die along with Safari for windows?
Right. Browsers can't use the OS control implementations, because the demands of DOM/CSS simply can't be handled by those native implementations. But Firefox is trying to emulate the look and feel of the OS controls, using native theme drawing APIs when possible. It is very hard to get 100% right, which is why no browser does.
Safari on macOS uses native controls. The reply button I'm about to click to submit this comment is 100% native, because Hacker News is using nothing fancy beyond <input type="submit" value="reply">. (Interestingly, Safari will outright ignore font sizes it cannot draw a native control for…)
To understand this better, here's a good place to start in the Webkit source code: https://github.com/WebKit/webkit/blob/master/Source/WebCore/...
That is the interface Webkit uses to draw "native theme" buttons and other controls on Mac. It is not using a real Cocoa NSButton for each button in the Web page. Instead, it creates its own internal DOM and CSS rendering objects (HTMLButtonElement, RenderButton respectively) which are cross-platform code. Every time it needs to draw a button, it calls virtual methods on RenderTheme. On Mac, the RenderThemeMac implementation calls down into Cocoa code to draw the background and borders of the button. (But not text; that wouldn't work in general, because in HTML a <button> can contain arbitrary HTML elements, and native buttons can't handle that.) That's pretty much the only involvement of Cocoa native button code. Firefox works in a very similar way; here's the Firefox version of RenderThemeMac: https://github.com/mozilla/gecko-dev/blob/master/widget/coco...
I am only familiar with WebKit, but glancing at the Firefox code, it looks quite similar. I'm actually not sure what you're claiming? Both implementations rely on NSButtonCell to perform button rendering when possible, and fall back on drawing it by hand if you mess with it too much (for example, if you set background-color: green on it). Then it hooks up internal DOM objects so they can be manipulated using web APIs.
> Browsers can't use the OS control implementations, because the demands of DOM/CSS simply can't be handled by those native implementations. But Firefox is trying to emulate the look and feel of the OS controls, using native theme drawing APIs when possible.
Then Wowfunhappy wrote: "I wonder if that applies even to Safari on Mac and iOS". It absolutely does, Firefox and Safari work the same way here. But you appeared to think you were contradicting us when you wrote "Some of them are native, if you don't style them."
I guess it boils down to what you mean by "Safari on macOS uses native controls." Drawing with NSButtonCell and the other theme APIs does not, in my view, warrant such a blanket statement. All of the interactive behaviour of buttons and other widgets is (re)implemented by Webkit/Gecko. Accessibility is reimplemented. Layout is reimplemented. It's only painting that uses NSButtonCell, and not all painting either (borders and background but not the text).
I would certainly never claim "Firefox on MacOS uses native controls" even though it works pretty much the same way as Safari.
I would call that quite native, because you can see what they do when they can't actually use the platform APIs. In my mind, blitting pixels onto a screen is non-native; using a NSView/NSCell or similar "generic" view and drawing into that wouldn't really cut it either, but using an actual button cell is basically as native as you get. Like, that platform API exists for exactly the thing Safari and Firefox are using it for? I'm not saying that they're rendering and interacting with the web natively–that would mean they're translating divs into NSViews and text into text components–but for controls they are using honest-to-goodness AppKit controls that they have hooked up to web APIs. What is not native is what they do when you mess with them, as I described.
The drawing code is not what people typically mean by "native". What they mean is the behavior. No browser relies on the built-in behavior of e.g. an NSButton. The source code of "native" Mac apps looks nothing like RenderThemeMac.cpp.
On macOS the situation is interesting because there is a sort of an “in-between” later that doesn’t really seem to exist on other platforms, which is cells. Usually you either have a control or you have a drawing primitive and you get nothing in between, but on macOS you have a class that encapsulates the drawing portion of a control and you can hook up your own event system on top of it. Safari has it a little bit more complicated than this because it needs to handle basically every possible abuse of NSButtonCell before it falls back to something completely custom; Mac apps typically don’t style their buttons in a dozen different ways. Safari can’t actually use NSButton because such a class obviously can’t be hooked up to the DOM: it wouldn’t be worth it. But if Safari actually included a full reimplementation of NSButton, it would be significantly more complicated than what we see here. It is still relying on a lot of NSButtonCell functionality, which as you mention is just drawing but includes behaviors like highlights and sizing and animation which people who actually do try to reimplement have historically done poorly. (Actually, to be completely honest, Safari actually does break a couple of things as it tries to disable built-in behaviors. But this is coming at it from the opposite direction from usual.) I know it isn’t sending NSEvents around but it “feels native” and works with the web: it looks, acts, and even updates like a button but makes an event in the web page, which is I think the best anyone can do. (FWIW, iTunes does its own thing too, and it’s native as well. It’s just bad native.) At some point, when they’re using a significant portion of the platform’s native control and are working hard to hook it up to something which isn’t what it usually is connected to, to the point where people who generally have complaints about “non-native UIs” (hello) sit back and say “actually this is not too terrible” I think you have to give it to them.
Edit: I thought more about it and I think I was misunderstanding where this conversation was going. I do care very much about native controls being more than looking native. The thing is that in the web really the only thing exposed is how the control looks because all the platform behaviors have to be stripped out: for example, on one OS a native control with the word “OK” inside of it may be implicitly activatable via the pressing enter on the keyboard, but such an interaction is undesirable on the web because a button should have the lowest common denominator of behaviors. There really is no room for much more than the actual UI of a control to show platform conventions and so when I call things native in this context I mean that they are native as they can be used in a webpage. Plus more complex interactions, which is often where such “native” frameworks go wrong, are just not a thing on the web so I am using ignoring them while you are not.
I guess you can use the word "native" to mean whatever you want, but I assure that (as a former Mozilla developer) if you claim "Firefox uses native controls" (because internally it calls into platform APIs for some rendering sometimes), people are going to get mad at you.
Yup, I know both you a Patrick work(ed) on this stuff, hence why I will from this point on stop claiming things about Firefox as I have not done more than glance at the file you linked. However, as someone who is fairly familiar with WebKit and even worked on it for a short period, and as someone who happens to be a person who gets mad at others at claiming that they are designing “native” UIs: I think calling what Safari does as “native” is a better description than saying it is not. (To give you an idea of where I tend to draw the line: Flutter is not native. Qt is not native. React Native uses native controls, as does wxWidgets.) I think of you asked a random software engineer how they thought web controls were implemented they’d guess that they were drawn and implemented from scratch in the browser, and some browsers (like Chrome) actually do this. What Safari does isn’t drawing a rectangle on a screen using Quartz: it’s actually pulling the class that defines the UI of a button from Cocoa and putting it on the screen, making sure it stays consistent with the DOM. There are actual AppKit engineers working on this and they call these native controls. Safari sometimes needs to disable or patch around bugs in them. It’s basically as close as you could possibly get while still being able to use one of these in a webpage.
Edit: as I mentioned in another comment, what I’ve really been trying to say isn’t that they’re as native as the web will let them be, and that happens to allow them to use a fair bit of platform-specific code if they would like. I think the things you are trying to bring up are just a consequence of the web not being a native platform.
You can't tell by looking at the controls whether Safari is using the native control implementation (it isn't). All you can tell is that the Webkit implementation looks like and acts like the native implementation.
> Browsers can't use the OS control implementations, because the demands of DOM/CSS simply can't be handled by those native implementations. [...] It is very hard to get 100% right, which is why no browser does.
This is not correct. In instances where CSS doesn't affect the styling of the control, the browser can use native controls. As far as I know, every browser _except_ Firefox does this. For example, <select> elements in Chrome and Safari are native elements (albeit Win32 versions in the former on Windows).
Chrome and Safari are absolutely not using the actual native control implementation. E.g. on Windows Chrome is not jamming a combobox HWND into its browser window.
> In instances where CSS doesn't affect the styling of the control, the browser can use native controls. As far as I know, every browser _except_ Firefox does this.
This is not true. It's not just the styling of the control itself that makes it infeasible to just stick an NSButton inside the browser's NSView; it's about the way a control interacts with everything else on the page.
It seems that it's faster on every website I use except Gmail, Google Voice, and Youtube. I wonder whether Google is using some sort of Chrome-specific javascript to make those sites run faster in their own browser?
I'm not sure if this is still the case, but Youtube used to use WebComponents v0 which has to be emulated in JS in non-Webkit browsers, since only Google ever implemented v0, while everyone else agreed it required a bit more work, and other engines run v1 instead, which is not compatible.
The main YouTube site seems to still be lousy in Firefox. Buttons that should open dropdowns (e.g. the top right corner user icon and notifications icon) don’t. If I want to actually see notifications, I need to tack ?disable_polymer=1 onto the URL and experience the ancient site!
YouTube Studio doesn’t suffer from these problems.
I have no idea when it stopped working, because I scarcely ever used the affected buttons until very recently—I have a vague feeling it might have worked three or four years ago, but in the last couple of months it’s definitely not been working for me.
uBlock Origin is the only extension that I have that could feasibly alter anything, and all it’s doing is blocking googleads.g.doubleclick.net. Nothing of interest shows up in the dev tools. 99.9% sure the bug is with YouTube, though in what particular way I cannot guess.
Ah hah! Figured it out: some cosmetic filter is killing the dropdowns. Unfortunately the effecting rule is not discernable in the dev tools, so figuring out which rule is at fault is tricky and slow.
Found which one, too: it was a rule of my own that I added almost a year ago to kill off some of the annoying cards they pop up at the ends of many videos, which hide the video content; turns out my rule was just a touch too broad for how they do things.
It doesn't exactly need to be Chrome-specific; every browser/JS engine will have slightly different performance on different workloads, so Google just has to lean heavily on things that are golden-path for Chrome. They could even do this accidentally/nonmaliciously just by mostly testing on Chrome and not testing performance on other browsers.
Wouldn't it rather be "Maintaining and not fixing" rather than "Designing"?
Google is perfectly allowed to make mistakes or forget something. The criticism is that this is a repeated behavior, as if they decided that it is never going to be a priority.
Nothing specifically malicious. Since Chrome is default browser at Google, it’s used as default development and profiling browser, and then it’s ported to and tested on other browsers, obviously not as much.
Concerning form input styling, many of the responses that have been made before this time are broadly technically incorrect or insufficient (roca’s comments are excellent, as a developer in this very space), and no one’s mentioned that work is actively happening in this space.
On Windows, Firefox currently uses Windows APIs to draw the form controls, scrollbars, &c. where possible, and imitates the style in the places that there is no native API for it.
My opinion: the new control styles are… fine, I guess; but they could do with some not-flatness (especially for buttons), and increases in size and padding are seriously problematic on many existing sites.
My LOD 3D models still take ~10ms per batch to load from binary file in Firefox, whereas Chrome needs ~1ms per batch. Mostly because of DataView but Mozilla recently assigned someone to work on it so I'm hopefull for the future.
I recently switched to Firefox after being a Chrome user for the most part of my life. In the past I couldn't switch to Firefox due to a lack of alternatives for the extensions I use on Chrome (particularly Google Dictionary) but I recently use Firefox again and decided that the performance difference is worth the change. I still miss the extension options I had sometimes but I have to admit that my overall browsing experience is markedly improved on Firefox. Glad to see that my anecdotal browsing experience is backed by benchmark.
I ran three trials of each on a min spec 2019 MacBook Pro 16". All numbers are ms rounded to the nearest integer, all browsers are latest stable. I also loaded the page with dev tools closed since that affected times.
Thank you to the Firefox team, this seems like a really nice release. I am very happy about the "If you don’t have a master password set up for Firefox, Windows and macOS now requires a login to your operating system account before showing your saved passwords." change. It might seem like a small change, but it's one of those friction points (another password to remember!) that will lead to (hopefully) more people using the built-in password autofill. Thank you again!
Anyone with a security background or someone who has thought through this more: what are the implications of making the OS level authentication the default, and then only ask to make a master pwd if there are no OS level login pwds? Is one or the other more secure?
Personally, I don't like operating systems that train users to enter login credentials while using the system as this increases the chance of someone capturing those credentials via spoofing.
I used to think Firefox trying to protect the entered passwords made some sense, but I've been convinced it isn't really such a good idea. Better would be a full profile being protected (with all files encrypted), or just rely on an OS level lock screen for inactivity lockout.
I'm not sure if the current system actually prevents recovering the passwords. Do they require this authorization even to use a show password option on a website or the equivalent effect via bookmarklet-style javascript? I suspect they don't and it doesn't try to protect from intentional theft only casual viewing of passwords. This might still be valuable for some people, but it would be more valuable to fully protect the profile. I worry that people will think they are more protected than they actually are and that this effect will be increased by the use of system login credentials.
Also, IMO the list of sites that you have passwords for should be treated as just as sensitive as the passwords themselves. I think as is you can often see the sites with accounts, visit them, and have the current password autofilled into the old password field of the change password dialog.
The "generate password" option is great, even though personally I would make it 21 characters rather than 15 (there might be an option for that?). IMO, no one should ever choose a password.
If an adversary can get user access, they generally are able to also get root access (via social engineering or a local vulnerability). They'd also be able to read the memory of the web browser, or file contents. This is because on an average desktop, all the programs running as user have read/write access to each other.
On mobile OSes, capabilities are enabled by default. Even Symbian already had such. OpenBSD utilizes pledge to minimize impact.
Thanks for taking the time to pen a thoughtful response. I really appreciate the point about training users to enter login credentials, how it might be risky, and also that this could lead to a false sense of security.
That being said, I do think that these features will overall lead to better password hygiene for people who do not have access to the kinds of info we have (especially where FF warns about passwords shared across sites; that's a feature that iOS does fairly well; in KeyChain, they show a warning label next to a password shared between multiple sites).
P.S. The point about securing a list of sites that you have passwords for is fantastic as well.
This is a great feature. I always added passwords to the browser auto-fill without thinking, and was shocked to find out that these are viewable to anyone without any password by default.
Honestly after getting used to it I like the change. Why? Because before it was often not easy to see if the input focus was on the address bar or somewhere else, and often I'd start typing and the input land somewhere I didn't expect. Now at least it's very clear, although I agree they could have done it better.
I'm using up-to-date Firefox, but I toggled the about:config flag to get the old address bar, figuring I may as well use it while I can. Here is what the address bar looks like for me:
Oh, that's intentional? I had no idea what was going on and am just now realizing I haven't had a weird bug or something this whole time.
edit: just remembered because it happened again. I'm not sure if it's related but I often find now that when I type "n" the bar doesn't autocomplete "ews.ycombinator.com" with the rest of the text highlighted anymore. It still goes there if I hit enter, though.
I noticed this after upgrading my OS and thought something horrible had happened. Turned out to be true but it was intentional by Mozilla. If it's not broke, break it I guess.
In the last update (75) I had this bizarre problem that any amazon.co.uk links in my history weren't showing up in the "most used links" that the url bar is usually populated with if you click the down arrow (or in this update where the down arrow used to be)
I have a browser profile that is used almost exclusively for amazon content as well. The most visited links in that profile are amazon.co.uk and prime video but the only "most frequent" links it would show were on twitch and the occasional youtube page I visited to find trailers for amazon hosted videos.
When I went to about:config and toggled the four "update1" bools to false, amazon came back in my "most frequent" links.
Pretty strange, eh?
Edit: so I just installed 76, and switched the four "browser.urlbar.update1" bools that enable this back to "true", and again, any amazon.co.uk links are removed from the list I get when clicking on the empty urlbar.
I don't really care about the ugly styling, but since this is a navigation feature I use extensively, I'm turning the whole thing off again. Hope they fix (or document) this before the choice disappears!
Wow that's sad. Firefox's URL bar completion behaviour was one of its biggest advantages over Chrome. I wonder what the logic behind changing it is, and if it will lose that edge.
The new searchbar uses the top sites from the new tab page, which is a different algorithm from the one used for the old list (which I don't understand either). However, the one upside to this is that you can edit the top sites from the new tab page, and the edits will show up in the searchbar dropdown.
My "new tab page" is always set to just blank page and has been for years. I dislike all the fancy new page stuff and just set it to blank page on initial install.
The sites that show up in the urlbar dropdown are frequently visited ones, same as the ones that show up when I turn the "update1" stuff off, or the ones prior to ff 75, just not sites containing amazon.co.uk.
So while I don't doubt your information, it doesn't make sense to me as an explanation. Maybe not having any sites in a new tab page is some kind of corner case that exposes a bug. It's weird that amazon is specifically affected though!
I probably should, but I'd half expect to be told that this is intended behaviour due to some "clever" feature that knows better than I do how I want to use my browser.
The pop out address bar didn't bother me either, because I don't use the bookmarks toolbar.
My GF hates it because it partially obscures the bookmarks toolbar on any new tab. So her everyday usage is impacted where she opens firefox and clicks a bookmark. She hated it so much she looked through reddit threads and modified her about:config to make it go away, which is really saying something.
The first time I saw it, I thought it was a UI bug. Is it supposed to expand, cartoonishly, beyond the confines of the existing bar, when you select it for input? It feels like an element designed as a helper for people with limited wrist/hand mobility (who need a larger target area) or poor eyesight.
I guess I'll head back to SeaMonkey now. The UI hasn't changed in a decade but at least the UI hasn't changed in a decade.
Yeah as somebody that uses the bookmarks bar, this is just maddening. First I go to about:config on my personal profile, great. But I have a work profile, and once again I have to turn it off. Dev Edition gets the update, gotta turn it off there. Login to desktop at work. Repeat all 3 of those. Oh, work laptop also needs all 3 to get updated. Then I move to my MacBook, gotta turn it off again. Power up my old Dell XPS13, god damn it I have to turn it off again...
I mean, anything related to aesthetics is going to have some difference of opinion. Mozilla appears to have concluded it's the people who dislike the address bar who are a verbal minority, or they wouldn't have gone with it.
And who knows, maybe Mozilla is right—but I wonder if they've actually done large-scale feedback gathering. This isn't the sort of thing you can suss out just from looking at analytics.
You'd think .. but no: Google is the default homepage, so they type in to the search field. It's mad.
Some have Bing as their homepage, if you've ever done IT training you might know the next line. They do it differently, they type "Google", click a link to go to Google, then type "BBC" (say), and click on the link for "bbc.co.uk". It's insane.
It's just the HN effect; complain about the most minute details. Firefox simply wanted it to be more obvious that the address bar is in focus the moment you open a new tab.
Reddit was pretty annoyed too. I actually did a little real-life poll (I admittedly might care about minute details too much!), and everyone was either indifferent or negative. Indifference was more common, but, is that really a good outcome?
> Firefox simply wanted it to be more obvious that the address bar is in focus the moment you open a new tab.
Is that it? Because I'm still trying to figure this out! I'm just really surprised that this was a problem for a substantial number of users—the address bar already had a very prominent focus state with its thick blue outline.
Indifference shouldn't be surprising for a minute detail. I didn't even know about the feature until I saw this thread (clicking address bar expands it), since I normally immediately start typing once I open a new tab.
I'd even argue that indifference should be the goal when making design changes; make subtle changes over time instead of the complete overhauls that are common today.
It is possible to fix UI problems without people noticing.
Also, people quickly get used to suboptimal UI and all kinds of UI bugs. Fixing those bugs improves the experience for new users while acclimatized users will be indifferent or even hostile to the change. It's a classic dilemma for long-lived products.
I'm shocked that was the goal but I also couldn't grok the intent. The bar doesn't need to expand and look silly to make it obvious it's the selected input. We have perfectly adequate elements for that already. I assumed there were new features that they were trying to highlight in a non obvious way.
> the address bar already had a very prominent focus state with its thick blue outline.
Either I never noticed or that very prominent focus state was invisible in the theme I installed. So yes, it was definitely one of the most regular issues I had with Firefox and now it's fixed. Not in the most elegant way but it works for me.
>Indifference was more common, but, is that really a good outcome?
Indifference among people already using Firefox is a good outcome if it is viewed favorably by people new to Firefox, which is who I would guess these kinds of changes are aimed at.
If that was all it did, fine. It also does the suggestion list on focus rather than after you begin typing, obscuring the page. This makes click-and-copy to get the current URL a destructive action - you need to click outside of the address bar to see the page you were already on. The new "equivalent" is using the tiny ellipsis menu, a Fitt's Law fail.
Neither clicking on the URL nor hitting the keyboard shortcut to bring focus to the address bar is a destructive action. The URL is still in tact, and you're free to copy it immediately after either action.
Yes, I still don't like this. I've got used to it, but when I was testing it on Dev edition of FF, it was covering half of my bookmark toolbar, and I couldn't get over it. I wish they had a setting to toggle it, which I think a browser like Vivaldi would implement.
They should just put a toggle for it under the Customization page. I think that would be the simplest way to placate peope that dislike it. (Yes I know you can about:config to fix it, but a toggle makes more sense.)
I can handle about:config, but if they take it away, that will be very frustrating.
For me, the bigger address bar is just as bad as an advertisement: it's trying to steal my attention, except in this case no one else is benefiting from doing so.
If they remove the option, I hope someone smarter than me can come-up with an add-on to fix it.
That seems insulting to the Firefox devs. Firefox's devs are clearly better than that. The Customization page is pretty bare, they can still add it there without looking like your image.
What a time. Now every option is either a) not available b) hidden somewhere where you need the Internet to find it (chrome://flags, about:config, registry ...) and c) probably removed in the next update because "people didn't use it anyway"
The picture you posted is a positive example. An example on how to customize the software you use.
> I'm still trying to figure out what UX problem the expanding bar was intended to address.
Possibly the same as removing navigation arrows from the context menu if text is selected, i.e. to annoy long time Firefox users like me?
Certain features should be compile time options, default off and then we could make a UX-designer edition with all the crazy stuff just line we have developer edition.
Then I and everyone else could continue you use the old ux that actually worked very well ;-)
>Firefox now supports Audio Worklets that will allow more complex audio processing like VR and gaming on the web; and is being adopted by some of your favorite software programs.
> With this change, you can now join Zoom calls on Firefox without the need for any additional downloads.
It's unlikely that AudioWorklet will fix a video call issue (zoom is alone in using it, because it doesn't use regular WebRTC facilities), but we're aware of performance issues, and they are being addressed.
In particular the graphics layer is being rewritten (the WebRender project), and exciting new developments are coming these days (in particular usage of the OS compositor to composite some bits of the page, that saves lots of watts).
This is particularly important for video calls, because often you're playing back multiple videos at once, so any inefficiency when compositing video is made worse.
Other things that are coming is to implement new ways to signal temporal or spatial scalability (telling other peers that videos flowing should be lower/higher fps, lower/higher resolution), this will also help.
Jitsi doesn't use AudioWorklet as of now (and doesn't need to).
We're continuing the work so that jitsi works well in Firefox, there are a few things remaining, but less so than a few weeks back (I'm more on the audio side, and those issues are mostly signaling or networking related).
On my Windows setup running on Bootcamp, the previous versions of Firefox had trouble accessing the microphone for many of the video call providers while Edge and Chrome are working fine.
>>> CVE-2020-12387: Use-after-free during worker shutdown
>>> Impact: critical
>>> A race condition when running shutdown code for Web Worker led to a use-after-free vulnerability. This resulted in a potentially exploitable crash.
And:
>>> CVE-2020-12388: Sandbox escape with improperly guarded Access Tokens
>>> Impact: critical
>>> The Firefox content processes did not sufficiently lockdown access control which could result in a sandbox escape. [On Windows]
So a sandbox escape and a way to be in a position to need a sandbox escape.
Firefox made a huge mistake following in Chrome's trail with the version numbering scheme. I just don't care about Firefox 76, is it a big change? Is there some new feature I would want to try? Who knows, I'm sure Firefox 77 will be out soon though!
I want to figure out who to talk to on both Firefox and Chrome sides to beg that they adopt a scheme like YYYY.MM.minor for their version numbering. I believe that would be superior for basically everyone—web developers, users, &c. (In the case of Firefox, it works especially well since they’re releasing approximately monthly now. I could imagine people on Chrome puzzling over why some month numbers got skipped—not that people actually look at those numbers often.)
I agree. The first thing I think when I see a version is "how old is this?". Version numbers as they are now are completely arbitrary (nobody really follows semantic versioning no matter how hard they try). Might as well encode some useful information into them. I'm thankful a lot of the Linux stuff I use follows this.
There's also the fact that Firefox is now on a 4 weeks release cycle, which means there will be months with two releases. (and that's ignoring chemspill releases)
It's suboptimal to have to change the number of the next release during a release cycle. That would mean, for example, that Firefox Nightly 2020.11 might correspond to a Firefox release 2020.12.
What’s the advantage behind a more complex scheme? It doesn’t seem to add anything. The current system just notes the specific release in a series of releases.
if you strip out the periods, it’s still an increasing numbering scheme, assuming there’s fewer than 10 minor releases in a month, which seems highly likely.
But in real life as a developer, not all of your users are using the latest one. If you depend on a certain feature, it’s a pain after looking up the version that started supporting it, to then have to look up what time that number corresponds to. (e.g. “that’s last month’s browser” is a bit different from “that got fixed in the browser two years ago, please update”).
A moment where version numbers are relevant is when you collect telemetry from your users and when you reccomend supported browsers.
I think it is in part a difference between websites oriented to the public and websites oriented to companies, where browser versions can be more complex than a self-updating browser.
Sorta. Though in that case, more versions is more better - it gives you more precision on the up-to-date-ness of the browsers people are using. Rather than saying "80% of people use a browser from between 2016 and 2018", you can say "75% use one from late 2018".
You are aware of the long term support firefox esr, right? Because the existence of that invalidates the "only the latest gets security fixes!!!" argument.
How is that addressed by a more traditional version number? There are many examples of major software upgrades reflected by a change in minor version number, minor software updates reflected by a change in major version number, or a major new release having less functionality than the previous version (e.g. Final Cut Pro X). With mature software like Firefox, what even is a "major change"?
Firefox and Chrome already release on a fixed date schedule instead of a feature based schedule. The proposal is to simply use the date in the version directly instead of indirectly.
"Major release" also doesn't matter like it used to. One of the big new features in recent versions of Firefox is WebRender, but that is being slowly rolled out among users based on CPU/display/platform, it's not a Big Bang feature release.
There is no right way to decide what is a major release. Whatever you do, some users will think a major release should have been classed as minor, and vice versa. It's ultimately easier for everyone if you don't make the distinction.
Firefox 76 or Firefox 5.6.6 makes no difference to me really. With browsers everyone should aim to be on the latest version and definitely not very old versions. To know if Firefox 76 is the latest or really old you need to get some more information. I wonder if anyone has tried to do it as follows:
Let the latest version be called Firefox and then adjust the previous versions to Firefox -1,-2,-3,-4,-5.. -76
> Firefox displays critical alerts in the Lockwise password manager when a website is breached;
>If one of your accounts is involved in a website breach and you've used the same password on other websites, you will now be prompted to update your password. A key icon identifies which accounts use that vulnerable password.
I really want to use Firefox, but they’re just stuck with so many issues, then suddenly out of nowhere they make the address bar massive.
My personal annoyance, on macOS:
Cmd+Click a link:
- Safari, opens in tab in background
- Chrome, opens in tab in background
- Firefox, opens in tab in background
Shift+Cmd+Click a link:
- Safari, opens in tab in foreground
- Chrome, opens in tab in foreground
- Firefox, opens in tab in foreground
Cmd+Click a bookmark:
- Safari, opens in tab in background
- Chrome, opens in tab in background
- Firefox, opens in tab in foreground
Shift+Cmd+Click a link:
- Safari, opens in tab in foreground
- Chrome, opens in tab in foreground
- Firefox, opens in tab in background
For some reason it’s different for the bookmarks. I opened an issue https://bugzilla.mozilla.org/show_bug.cgi?id=1597910, because really there is no actual reason to make them different, but it was closed on the basis that it might disturb the muscle memory of some users. But changing the entire menu bar is completely fine?
Hearing good things about firefox performance vs. chrome in this thread, I thought I would have a look at firefox use of rust - I found this informative page which provides a lot of rationale for where rust has been used:
https://wiki.mozilla.org/Oxidation
Here is a cut of what was introduced in Firefox 76 (copy&paste)
Integrate fluent-rs, a localization system: bug 1560038 (shipped in Firefox 76)
Why Rust? Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.
I wish there were more options to control tab priority and UI latency in firefox.
I have a respectable (2x8 core xeon, 164gb ram) workstation running linux and I have many tabs/windows open with various references spread across virtual desktops optimised for tasks (work project 1, 2, education, personal project,... etc).
I've experimented with various extensions that pause tabs and currently use tab wrangler to auto-close tabs but it still gets slower to respond with ~50 tabs open across all windows. Sometimes I check the firefox & system task managers to see some basic reference tab (i.e. blog post) taking most of the CPU...
It would be great to be able to aggressively throttle inactive tabs or even pause them completely so only ram is used.
Some options around this use case would be much appreciated. Responsiveness under (almost) all conditions is much more important than raw benchmark throughput. Near instant tab resuming would be a huge help towards this goal as well.
I've been using it since it was introduced. I no longer think about my passwords. Everytime I register in a new website, I just right-click -> generate secure password, it auto-fills and saves it. One password for every website. Yes, they are stored remotely with Firefox Sync.
Can you use it as a password manager for things that are not websites as well? And is there a way to associate additional data together with the passwords, such as answers to security questions?
Those were the two main things that made me use a separate password manager app in the first place.
No to both of these. There are only three fields, and they must all be filled in: URL, username, password. But suppose your bank is HSBC, you could, make up something like "securityquestion://www.hsbc.com", "mom's name", "Jane Doe".
Sadly it doesn't really support customizing the generation. There have been plenty of sites I've found where the auto-generated password doesn't match requirements of the service.
Its just the browser's normal 'save password' thing, but now with great UI for managing saved logins.
E2E encrypted with your Mozilla account password. If you forget your password and lose/reset every device that you have firefox installed on, you will lose the database. The firefox lockwise app is a login db replicator/ui for devices you don't want a full FF install on.
I've been using it for years since, again, its just the normal save password function that's existed for decades. Completely frictionless experience. The UI, accessible through the menu or about:logins, has options now to manually add/edit/copy logins. And it suggests auto generated random passwords when creating new accounts.
It also pairs with an app called Lockwise now! It means you can generate passwords and even auto-fill them in other native mobile apps these days. At least I can fairly easily on Android. Found it much easier for my luddite to be comfortable adopting over things like LastPass/OnePass.
There can be some weird situations that you need to be careful of. For example, if you jump on your partners PC, log them out of their Firefox account and log into yours, all of their passwords / history etc gets merged into your account. You need to learn about Firefox profiles to get around this.
Also, the old Firefox had a way of clearing all saved passwords from the Options menu. This is now gone, you can only delete a single password at a time. You need to enter the following URL into the Firefox browser, which will let you clear all your passwords: chrome://pippki/content/resetpassword.xhtml
I personally use KeePass, but I like having the passwords saved in Firefox so that they are accessible on all my devices.
I'm using it, it seems to work fine, and works/syncs on mobile as well (mobile Firefox that is, not for other apps AFAIK), and on my work computer's Firefox instance. I seem to recall attempting to change my Firefox sync password once and it notified my that I would need to export and re-import the passwords (IIRC), which I took to mean they are careful to never get full access to them unencrypted on their side. While less convenient, I like how that's set up if it's how I think it is.
For every device I have logged in with Firefox sync it just works as you would expect.
Maybe it sounds silly but make sure you have access to the email associated with your Mozilla account. I learnt the hard way after reinstalling Windows that Mozilla sends a confirmation email to this address when you set up Sync on a new system. It turned out that I had no access to this email anymore since the provider went out of business. I was told it's impossible to access my sync data. Thankfully I did not use it to store any passwords (I use KeePass for that) because otherwise it would have been a catastrophe.
I use keepass as well and there is a similar conundrum. If you store a backup of the keepass file on a remote server, make sure the passwords to access this remote server aren't only in the local machine keepass.
Wait but, you had no backups? I don't mean email access or sync access, but simply a backup of your system with your photos, documents, application data (including firefox' password database), none of that?
> Anybody using Firefox password manager that can comment on it? Is it considered safe enough?
Have been for >10 years now. It feels kinda icky because of how close the passwords are to every website I visit, but the convenience of having passwords auto-fill enables me to auto-delete cookies of most sites (reduced tracking without compromising on convenience) and not hesitate to use a strong password. I've heard of way more bugs in third party auto-fillers than in Firefox' own, but that notion is of course not scientific proof.
I do think that if you want real security, you need to have the passwords on a separate device (for example on a phone) since malware has been known to keylog and steal password databases. Keylogging is not really possible on a phone unless you grant the offending app some very odd permissions. Whether a separate device is worth the hassle for you depends on how big you judge the risk for the accounts you'd store in there. Not using autofill or browser integration also helps in case there is some security issue in that, but I'm not sure how much that really helps (most browser bugs are aimed at running code on the host anyway) and how much it's just a nuisance.
No: Mozilla have access to your passwords if you use the Sync feature.
They encrypt your passwords with a key encrypted by a key generated from your Firefox Account password, and you enter that password on a web page they serve from servers they control. At any point they can start or stop serving malicious JavaScript to one, many or all users logging in, and steal your master password, then use that to decrypt your stored passwords.
Yes, they could also target users in Firefox itself, but that would leave traces in the Firefox binaries, and users should not automatically install Firefox updates the way they 'install' JavaScript on every page load.
If you do not use the Sync feature I believe that the password manager is okay enough.
I have a huge problem with how Firefox handles asking for a master password (if you want your password to be encrypted on disk).
Sometimes a small pop-up windows opens and ask you to fill your password. No other indication of which tab, which site, of even which Firefox profile opened it. It is not always the active tab. Also after unlocking it remains unlocked indefinitely.
Lockwise itself works nicely, it is just a reskinned version of the usual password manager.
Before you commit, you might want to know that there is no export feature.
It's really nice. Better than any other browser password manager. I've resisted using the browser's until now (I have 1Password) but the sync feature is slick for iOS.
Two things prevent me from switching away from 1Password: 2FA token support and shared credentials between multiple users (a shared family vault in 1Password). I could probably deal without the latter, but I definitely don't want to give up my auto-fillable 2FA codes.
The only thing holding me back is iOS support for changing the default browser. Here's to hoping the rumors about iOS 14 are true, and I'll be able to switch everywhere.
That shouldn't be a blocker for password managers. I use BitWarden, and it can auto-fill passwords in iOS Safari. So presumably there is nothing stopping Firefox from also sharing its password manager across whatever browser you use.
All the translate addons take you to the Google translate variant. It does not help at all especially when buying stuff from websites for example. I prefer the on-spot translation of chrome. The user experience is very bad with these translate addons.
Which is the reason I believe Google Translate cannot be used to implement this functionality by third parties. (like how DDG cannot use google's search results)
I sorely miss the ability to make my homepage a layout of the sites I visit daily. On Chrome I had this grid of most frequented sites that I set up myself, fine-tuned so I could launch Chrome and immediately open up any mail, read the news, check some of the blogs I read, etc. On Firefox, I've been using bookmarks but that's not as effective.
I could be missing something but in case I'm not. You can enable Top Sites and customize them to your liking by removing ones you don't want and pinning the ones you do.
I highly recommend start.me as new tab page. It can be a bit slow to load so I use the singlefile addon to bundle it into a self-contained HTML that I set as my new tab page. Nothing else satisfies me!
You can do better than that, you can add custom search engines for most search bars on the web, triggered by key words.
Just go to Youtube.com, right click the search box and click the "add keyword" menu item. Then choose a keyword you want to use to trigger a Youtube search (I use yt) and confirm.
After that you can search Youtube from anywhere by just typing "yt cute kittens" in the address bar and hitting enter.
I have been loving Firefox for the last year. The only shortcoming for me is that video playback and animation playback (svg/js) is highly CPU intensive in comparison to Safari/Chrome. I basically open Chrome to watch any videos.
I've tried that in the past but it never seems to take effect. I don't know if there's some other config overruling it
Edit: That doesn't look like the config I'm thinking of. That appears to change to zoom for the current active tab, rather than per site. The config I'm thinking of changes zoom for every site
I just switched to Safari - to be able to set time limits to websites on my mac, as I am consuming too much news these days. This is not possible with Firefox as far as I know.
There are numerous Firefox add-ons that provide this feature, e.g. https://addons.mozilla.org/en-US/firefox/addon/leechblock-ng.... IMHO, the main benefit of using Safari/Screen Time for this is that it automatically syncs the same limits across all of your iCloud-connected devices, which is great. I know Firefox has a Sync feature but I'm not sure if any of the add-ons leverage it to provide a similar seamless cross-device experience.
Whenever I start up Firefox it tells me to wait a few moments while it updates. The browser obviously doesn't care about me. It has its own agenda. This is why I won't use it.
...how often do you start up Firefox? I don't think I've ever seen this.
I generally loath automatic updates, but IMO web browsers are the one place they make sense. If you need something a bit slower, consider switching to Firefox ESR!
I don't use Firefox often because of the constant updating that prevents me from using it right away. Chrome and Brave don't seem to do that, at least not in the same obvious way that Firefox does.
Ironically though, I wonder if not using Firefox much is the cause of that annoyance. In other words, Firefox usually waits for an opportune time to update, but if it's been closed for a long time, it likely decides that it's too out of date, and updating asap is critical for security.
I'll reiterate my recommendation for ESR, it's Firefox but for people who want less frequent updates. :)
They should be smaller downloads that install more quickly though, shouldn't they?
I'm not on Firefox ESR, but switching to Windows LTSC made Windows updates a lot less painful and less noticeable, even though technically the frequency is the same.
You can use ESR[0] version of firefox the equivalent of LTSB windows. Or use a registry hack[1] to disable updates for regular firefox if you use Windows.
It would be great if they just checked for updates on startup like almost every other program. I use powerpoint twice a year. I don't need auto update taking center focus on my screen, interrupting whatever I'm doing, every week that powerpoint gets a patch.
On Windows or macOS? You can install PowerPoint via the App Store on macOS, which is great. Only MS product I have that use the MS Updater on macOS is Edge.
Ah that happens to me too every once in awhile and it's absolutely infuriating every time. Classic UI fail. It wouldn't be so bad if it just asked for permission first.
It happened today! I just tried to open a new tab to look something up but the page comes up with this:
> Sorry. We just need to do one small thing to keep going.
> Firefox has just been updated in the background. Click Restart Firefox to complete the update.
> We will restore all your pages, windows and tabs afterwards, so you can be on your way quickly.
I was in the middle of something. I had a thought, a question occurred, and I
wanted to look something up on the Internet real quick. So I hit ctrl-t for a
new tab. But that isn't the "new tab" command right now. Firefox has entered
into an invisible quasi-mode that remaps ctrl-t to "restart firefox". But
not quite. It actually remaps to a command that locks firefox like a grab:
it's unusable, it refuses to load and display any more pages until I
click that "Restart Firefox" button.
Interrupting my flow by remapping keyboard shortcuts to non-dismiss-able
modal dialog with one button ("Click here and only here you idiot monkey" is what that says to me) is super-arrogant. It's patronizing and disrespectful. Saying "sorry" before you shove me doesn't make it any better, it just sounds obsequious.
I switched to Vivaldi yesterday. (The opening-a-tab thing today that I'm currently bitching about was to find something in my old history in FF.) I don't actually like it any better but it hasn't spat in my face so far.
my 10M datapoint uPlot benchmark runs in half the time, for both pure js (fake data gen) and canvas workloads (chart rendering). check out the console in [2].
however, i'm still waiting for the performance assessment in devtools to improve so i can get an easy summary as i can in Chrome.
also, better default form input styling would be nice. it's so...Windows 98....but i'm on Windows 10. :\
[1] https://github.com/krausest/js-framework-benchmark/issues/68...
[2] https://leeoniya.github.io/uPlot/bench/uPlot-10M.html