Great release.
I had issues with previous releases (58-60) on MBP, where quite a lot of pages would cause high CPU usage and in turn overheating of the machine but after this upgrade the problem (at least it seems so) went away. And it also feels snappier.
And now the dark theme also applies to address bar and hamburger menu which is nice bonus.
If this is true, I would finally be ready to dump Chrome. I had the same issues, and I couldn't figure out what was causing it, but the app regularly ran hot. Will give this round a go.
UPDATE: So far, so good! Multiple account containers open, lots of different websites that usually would cause problems, and so far it's running fine! Also had Ghostery left installed and uninstalled that as well as it also hogged CPU time on Chrome, so that may have had an effect. All in all, think this is g'bye, Chrome.
Sort of tangential, but as an account-containers user, have you found a decent way to achieve making the current container "sticky", so that new tabs opened in a given window go directly to that container?
I currently use Chrome's account profiles for this, so I have a desktop where my work profile lives and a desktop where my personal profile lives, and this makes links followed from other applications Just Work so long as I'm on the right desktop for them. I could probably get used to a slightly more awkward workflow, and the history being annoyingly shared between them, but...
The problem is not having just one instance open all the links. It seems it might be possible to hack around that by writing your own url handler for your os, then dispatching to the correct instance. (https://superuser.com/questions/119014/how-to-remotely-open-...)
I did try that out, when I was seeing if I could stand switching after multiprocess stuff landed. It's closer to the fairly-polished Chrome experience if you use about:profiles, rather than messing around with custom command lines.
But, as you say, the problem with that is that it doesn't handle opening links correctly.
I could see if I could write a URL handler that queries the window manager to find the last Firefox window that had focus on the current desktop (probably possible, but I'm unfamiliar with that domain)... or I could view Firefox not supporting this natively as a sign that it doesn't think my use case is very important, and stick with a browser that works without jumping through hoops.
It's not that I'm averse to putting some work in, per se -- I'm now in the middle of poking at writing a Firefox add-on to see if I can fix my complaints about insufficiently sticky containers -- it's just that writing my own OS url handler is a bit too hacky for my tastes.
I have been using the Conex extension. It opens the new tab in the same container as the currently active tab and you can enable the preference to make it so that it asks you which container you want to use before opening an external link.
I've written my own now, which just approximates the Chrome behavior. (I looked at Conex after you linked it, and it didn't quite do what I felt was right.)
I did the same with Chrome account profiles, and I just searched for this on Firefox. The closest you get to it is ctrl/cmd + "+" (new tab button) which will open a new tab with current container.
Sorry, the main process goes to 140%, and about 5 more other firefox processes start chewing up 80% cpu each. I just added them altogether.
I have seen it spike to 400% a few times in activity monitor.
As to what I'm doing, open up say lobsters, click on all the tabs that look interesting, forget them for a day, repeat. End of the week have a look see at things.
For me the problem was only when firefox was running in retina mode. Going into Applications > Firefox > Right Click Get Info > Check "Open in Low Resolution"
The problem was fixed, but all the text looks bad now.
That's interesting. That fix seems unreasonable for me considering I already have difficulty reading on screens. But that's at least a point to look for later on in the release notes.
My personal test case will be with the UniFi 5.7/5.8 Controller web interface page. I've found consistently under the last few versions of Firefox that, while it's fine for at least an hour, if I leave it up constantly for ease of monitoring then after a day or two the Firefox process inevitably ends up pegging an entire core. There is no video whatsoever or any particularly fancy graphical usage, and while they may be doing something odd internally (I haven't had time to really dig into it) I'm not sure Firefox should end up in that state there over time. It's relatively easily repeatable though (will take a day but requires no interaction on my part) so I look forward to testing it. Although if it does resolve the problem I'll be mildly bummed whatever fix it was didn't make it into ESR, but so it goes.
I’ll try to repro myself first, already started up a test both on metal and a VM on a few systems. If it’s dealt with probably not much point investigating further. Should know within a day or two (or sooner, maybe it’s even regressed a bit). I’ll try to do a proper performance profile a report after that as well as ping a contact at Ubiquiti. They’d be the best placed to really dig into it.
I agree that if it's a leak on the Ubiquiti side they would be best placed to deal with that aspect, but there might be things we can do better on the Firefox side to handle pages leaking too...
After weeks of effort, a team mate finally figured out that a default noop function param, eg function blah( param = () => {} ), was never being gc’d. Wut?!
I recently wrote an automatic memory leak detector and debugger, which makes this a lot easier (imo) [0]. You write a short input script that drives the UI in some loop, it looks for growing things (objects, arrays, event listener lists, DOM node lists...), and then collects stack traces to find the code that grew them. While it won't find all of the leaks, I was able to eliminate an average of 94% of the live heap growth I observed in 5 web applications (which found new memory leaks in Google Analytics, AngularJS, Google Maps, etc).
More information about the technique can be found in a PLDI paper (which I presented last week :D ), which I tried to write clearly so that it is accessible to a technical audience (i.e., non-academics) [1].
I once used the Python function "gc.get_objects()", which returns a list of all objects in memory, to diagnose a memory leak. I don't suppose anything like it exists in JS tooling?
You can capture a heap snapshot in most browsers now using development tools. However, even a blank webpage (about:blank) has tens of thousands of objects allocated for the default JavaScript/DOM APIs. It's challenging to manually grok a JavaScript heap.
The approach I used was to take a snapshot, count up all the different object types (making a hash table mapping "name of type of object" => "count of objects whose type has that name", then discarding the snapshot), then take another snapshot a few minutes later, and see what the difference was, and which type of object there was suddenly a lot more of. Then I looked at various instances of that object. It turned out to be some async queue-related object that was only used in a couple of places, so that narrowed it down a lot. Even if it were something generic like a hash table or list, I suspect looking at instances of the object and breaking them down by some observable quality (e.g. number of elements, the set of keys in a table, the types of objects in a list), plus the differential approach, will take you fairly far.
There are some browser-specific tools that will do something like that out-of-band (e.g. in Firefox about:memory has a "Save GC & CC logs" option that outputs data about what the GC and cycle collector heap graphs look like). But interpreting those graphs is not easy, sadly.
For me it's the Microsoft Azure Portal that would cause Firefox to idle around 50% CPU utilization. For the moment it seems to be behaving. I opened up the UniFi Controller interface too just to test and it caused it to spike briefly but it settled back down to under 6% across 6 cores. So it's improved IMO.
I also had that, and it finally appears to be gone!
On the other hand, everything is blurry. I've searched to no end, and haven't found a solution. It looks like third-party apps used to when the rMBP was first released and apps that performed their own text rendering hadn't yet been updated to support it.
Any ideas?
Edit: I have no idea how this was even ever set in the first place, but a sibling comment mentioned the "Open in Low Resolution" flag that can be set on a binary, and it was enabled for Firefox on my machine. Either I set this manually trying to solve the performance issues (and somehow this setting persisted across uninstalls), or Firefox ships with this flag set. Unchecking it fixed the blurriness, and hopefully didn't bring back the performance problems.
It might have persisted across uninstalls (browser profiles often do), because people were suggesting the "open in low resolution" flag as a temporary fix for Firefox performance issues on Macs prior to v61 being released.
Out of curiosity, were these high CPU usages on pages with any sort of video playing (culprits for me were Twitch or any live stream)? I was also having these issues, and I want to use Firefox, but the performance in the past was just too difficult.
I had the same issues and avoided FF 57+ because of it. I just tried FF 61 and my results were mixed. Twitch and Youtube still made my CPU temps spike a little bit. It seems worse than Chrome but better than FF 57.
Google Maps, unfortunately, still made my CPU temp spike 30C+ as soon as I opened it. I use Maps a lot, so this is still a deal breaker for me.
Glad it's not just me. All of those really seem to stress Firefox out on my iMac. Chrome is far more efficient with something like Twitch.
Interesting thing I've noticed: If you don't use chat much and just want the video, try using Twitch's "pop-out" player that opens in its own window- for me this uses far less CPU (even in Chrome)
Chrome's "switch to fullscreen" transition on twitch for me is super laggy though, and I haven't been able to solve that one (Firefox switches to fullscreen smoothly).
I only use firefox (for privacy reasons). But the macbook-burning-a-hole-in-my-pants behaviour that firefox creates on these sites has led me to using mpv with youtube-dl to watch most of youtube and all of twitch. If you have both installed you can just do a 'mpv https://www.twitch.tv/username' and it will work quite nicely. You might need to set up mpv to get the best quality, I think putting 'ytdl-format=bestvideo+bestaudio/best' in ~/.config/mpv/mpv.conf is sufficient. HTH.
Which is so surprising to me because it's using the HTML5 video player and toggling around with hardware acceleration does nothing to fix the issue. Perhaps it's the integrated chat + any of the add ones that Twitch has written for the videos?
I have noticed the pop-out player seems far more efficient, which leads me to think the chat and other things going on around the video might be the culprit
I use Opera as my personal browser and it handles video pretty well. It's running Chromium under the hood, and I don't think any major improvements have been made for video in Chromium or in any of the standards like HTML5 or flash. I see on par performance to stock Chrome.
Unfortunately, this doesn't appear to be the case for me. I've been wanting to switch back to FF for some time but just opening a website causes my MBP CPU to go nuts, seems 61 is no different for me.
You wouldn't happen to be running Tab Session Manager, would you? That was causing me all sorts of performance problems on both PCs and Macs, and I only tracked it down by disabling all extensions and themes and then incrementally re-enabling them.
I am not, although you did remind me to try without any extensions enabled again. I can't do a straight comparison as I'm at work now, but my work laptop (2017 vs 2016) is showing improvements. For reference, my work laptop also had high CPU usage on previous releases (even with no extensions), so there's hope yet. Although not being able to use the extensions I normally use would be a deal breaker (blockers and such)
For me it just consistently hovers around 18% cpu. Chrome on the same site sites around 1%... could it be optimized for memory usage isn’t always better if it means more cpu usage?
> And now the dark theme also applies to address bar and hamburger menu which is nice bonus.
I have both normal FF and nightly FF. Before nightly getting the dark hamburger menu I'd never thought much of it. After nightly got the dark menu, now on normal FF I can't help but notice it every time I open the menu, and it annoys me to no end. Funny how these things work.
I wouldn't call it a great release. For me Firefox is unresponsive sometimes for literally minutes. I click on another tab and it takes minutes to switch to it. I just had it happen before posting this comment. I also took a perf profile and asked the people in #perf to look at it but nobody did.
Firefox has tools to figure out which tabs are causing problems, try about:performance. Any freeze of minutes is generally caused by a memory leak in the javascript of a particular page.
I thought the recent work on multi-process stuff would have gotten rid of that? The browser chrome not being affected by in-page issues seems like a fairly important goal there...
I have about 200 tabs on my work machine and something even worse on my personal one and have never seen this, so unless you're a serious tab hoarder I doubt it's that.
I'd be very interested to look into that, haven't seen it being stuck for minutes anywhere. Do you still have this profile around? or maybe just the URL?
* On-by-default support for the latest draft of the TLS 1.3 specification
* Convenient access to more search engines: You can now add search engines to the address bar “Search with” tool from the page action menu when on a webpage that provides an OpenSearch plugin
When I read that I was hoping they'd let me add a search engine to the existing "Select Text -> Right Click -> Search Google for '[Selected]'."
All I want is to be able to highlight page text and search YouTube, Amazon, or Google for it.
Right now I use an extension called "Swift Selection Search" but I'd prefer not to need it, the search engines are already part of the browser, I just need them on the context menu.
Personally, I was hoping for a Chrome-style "start typing name of website then hit tab to search that site". That's one of the biggest features I miss whenever I use Firefox.
Anyone else think the really significant change is going to be when Webrender finally enters the stable channel? It's already stable for me on nightly and is what makes the single largest difference to my experience, everything is so much smoother (instantaneous) and uses less resources. The reason I even switched away to Chrome from Firefox to start with was performance, I came back when FF's performance started eclipsing Chrome's again.
think the new option is actually gfx.webrender.all set to true, at least in nightly.
edit: just tested http://output.jsbin.com/surane/quiet in 61, doesn't seem to be enabled, going to try 62. Pretty sure they would have announced if it had been in 61, it's a huge addition, and it's probably coming in 62 when it's stable.
edit2: neither is it enabled in 62 (beta), also tried with the gfx.webrender.enabled option set to true just in case.
WebRender only works on Firefox Nightly regardless of what prefs you set. The code is #ifdef'd off in Beta and Release channels while there are still known bugs in Nightly.
Webrender won't run on older intehrated GPUs which don't support the required OpenGL level ( 2.2? something like that ). For example it won't run on amy of our four home laptops.
I can't imagine them enabling it by default until that user base is next to zero. I suppose they might prompt the user to flick a switch if supported but they'll still have to support Gecko for some time.
Those must be seriously old, because it runs fine for me on a 2010 laptop (on it's last legs) with a Nvidia GPU, it actually runs better than my other newer laptop which doesn't have a discrete GPU. Both have an Opengl version newer than 3.0 so that probably is the limiting factor.
> More customization for tab management: added support to allow WebExtensions to hide tabs
This should theoretically make it possible to restore the Panorama Tab Group functionality that I, among others, loved. Haven't tried 61 yet because it hasn't hit Ubuntu yet, but this extension should do the trick: https://addons.mozilla.org/en-US/firefox/addon/panorama-view...
Access to FTP subresources inside http(s) pages has been blocked
I thought immediately: what about FTPS (FTP over SSL or TLS)? So I checked, and apparently Mozilla has had a 17 year old feature request for FTPS support!
This request was only definitively rejected a few days ago with note of “vague plans” to remove FTP support entirely from Firefox, but no more info than that.
Although -- because it's a workaround for Google's implementation -- it only works for verifying keys, not registering them in the first place. If you add a key in Chrome(ium) then you can use it in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1436078#c4
I ported u2f-hid-rs (the library Firefox uses) to FreeBSD, it's been in the www/firefox port for a while and now accepted into mozilla-central I think.
The Chromium FreeBSD port also has had U2F support for a while.
I may have got this wrong, but IIRC, Duo use a Chrome-specific implementation; it’s on Duo to use the standard. I remember reading that it’s in their roadmap, but it didn’t sound like it was coming soon.
> More customization for tab management: added support to allow WebExtensions to hide tabs
About damn time. It doesn't seem to be implemented yet, though, as [1] still notes that it's not possible to hide the tab bar.
Checking my list, I think decent mouse gestures (that work on all pages and without having to have a page fully loaded) is the last big item remaining. I suppose I'll finally upgrade from Firefox 55 to 61 then, once this is implemented (or I'll implement it myself next month, when I have more time) and only have to say goodbye to gestures... took only about 9 months for them to get APIs implemented after breaking the vast majority without alternatives!
Looks like we should again start installing add-ons like we used to install the famous old toolbars, from executables/binaries which can modify things outside of the browser.
Hiding individual tabs is necessary for one of my own core workflow addons that broke with the recent changes: panorama/tab-groups.
With tab-hiding in, the "Panorama View" extension successfully replicates all the features I wanted from the old version of the addon.
Mouse-gestures/addons-in-system-page is still the last big gripe for me too, but even with the current limitations, the situation works well enough for me 80% of the time.
There are only 2 things keeping me from using Firefox as my primary browser at this point.
1. After the switch to Quantum, the part of the Lastpass extension that lets me copy my password from the drop down went away. It's a pain to have to open the vault every time I want to do that and it works fine in Chrome. I don't know what happened there, but it's enough of a pain that it keeps me out of Firefox.
2. Google Meet. I don't know if there's an easy way to open Google Meet links in Chrome automatically, but we use it for work and the IE6 style browser requirement is a problem.
Those 2 friction points are the only thing standing between me and a permanent change.
EDIT: Apparently the Lastpass thing is the only bit holding me back now.
Interesting, Google Meet now tells me to use the latest version of Chrome or Firefox.
If Meet fixed their end to use the latest standardized WebRTC instead of the previous Chrome-only flavor, I wonder why they refuse to let me use Safari? Safari supports WebRTC at this point. The site won't even let me continue anyway, it's forcing me to use a different browser.
I've been using Hangouts on Firefox a fair bit recently. Video chats work fine, though I've noticed occasional glitches with the UI if I leave it open after the laptop goes to sleep. A reload fixes it, though.
When I use the universal installer on Linux, I get a weird glitch in Firefox where the extension just vanishes after I type in my email address. Haven't tried it on 61 yet though.
I'd love to switch to FF. But does anyone know why the JavaScript debugger is so painfully slow? It makes debugging certain problems super frustrating as compared to Chrome. Is it doing more than Chrome is? Any chance this might be resolved one day?
I always get so excited for new Firefox releases. Then I read the patch notes and never see that they've fixed performance for MacOS. I've tried everything I can find online, but Firefox just performs so terribly on my Macbook Pro. In the meantime, I use Opera (with little to no complaints).
I've used 6 different Macs over the past decade and none of them have ever had this issue. I'm not saying that you're wrong about your experience, but that it's not like it affects 100% of Firefox's quite large Mac userbase.
I think the last time I ran into this issue it was a bug involving DPI scaling. If you're not running at the "default" scale, you'll have performance problems.
I wish they would add a setting for minimum zoom or remember my zoom levels after clearing caches. As it is, it does neither and the many add-ons that claim to do either don't work properly. It's fine to remove or not add functionality that's well supported by add-ons but this isn't by any add-on I've tried. The other major thing is the cpu usage while playing videos is simply unacceptable. A 2013 rmbp can't play one video these days? It can in Chrome without issues like skipping so this is just shit work by the ff team. Other than that I'm impressed by the browser. Dev tools are far superior to chrome especially the console. But after six months or so with ff, I've switched back to chromium. At least with chromium I know exactly which videos will play and which won't (drm). With ff, it depends on how ff feels that day. That is simply unacceptable for such a major browser.
Eh. Still using v56, since two crucial extensions are still unported to WebEx. These are indispensable to my workflow; I cannot even think of browsing the web without them.
I never used them myself, but I know I've seen recommendations for a few different extensions that provide similar (though not identical) functionality.
Is Tree Style Tab as good as it was before all the Quantum changes?
The last time I tried it in a recent Firefox, I had to modify the user chrome by hand, the extension was incredibly slow even on modern hardware, and there wasn’t feature parity with previous versions.
The only remaining quirk with TST I have noticed is that sometimes on launch, tab groups open expanded even though I had them collapsed. Then I have to first collapse any child groups before it agrees to collapse the whole thing.
Wow that is a lot of Github commits. The last release is about a month ago... Have you ever tried using the bleeding edge code? Looking at https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Yo... it seems like it might be possible, but you'd have to manually 'install' the extension every time you start Firefox...
Though I'm hoping with 61 "Faster switching between tabs" it'll be better. After changing the user chrome and updating I had to disable/enable the addon to get the tabs to render again. Sometimes when creating a new tab seems to be ungodly slow I can make it a bit better by going to the preferences and unchecking / rechecking the "optimize tree restoration with cache" box.
Still on pre-quantum on my home PC but I let my work machine update and have been keeping a hopeful "wait and see" approach since... It does seem to be improving at least. But the bug of closing the last child of tree triggering the loading of the next tree before switching back to the previous sibling (as specified in preferences) remains, it's going to be a while before it hits feature and behavior parity with the original.
I only started using Tree Style Tabs after it became a WebExtension. The userchrome.css stuff is still required, but it is documented and TST will link you to the doc when you first run it.
The usage experience is good for me. I had one weird bug where the TST panel would not correctly initialize in a new browser window maybe 10% of the time, but I cannot recall this issue happening in the last two weeks, so maybe that was fixed by an update.
My main issue with it is that if you close a parent tab and with it the children, and then undo the close action it restores the parent but not the children. You can then get the children back by repeatedly undoing the close tab action.
In pre-Quantim TST, you had the option when closing a parent tab to promote the first child, or promote all children. Are those options available? (For flexibility and safety, I use the former, and then “Right click -> Close subtree” as needed.)
Re. repeatedly undoing close tab (Ctrl-Shift-t (or Cmd) is what you mean?) I find that in FF 52ESR that it only un-closes up to the last 10 or so tabs. Do you know if that limit still exists?
Yes, those options are available for promoting the children.
It is still limited to 10. Just tried it again, when you (ctrl+shift+t), it restores the last one in your tree, as you build the tree back up by repeatedly undoing the close it does build up all of the children, then its parent, and so on up the tree.
Is that actually the case? I've read a few things that seem to imply they've fixed the timing attcks without breaking the spec, but this was all heresay and unsubstantiated claims.
It's definitely a frustrating experience to have to re-assign all of your containers if you happen to reinstall the browser. This should be easily supported by Firefox Sync.
Or if you happen to run Firefox between multiple devices. It's been a pain maintaining a couple of instances' synced when it comes to containers (again, such a shame).
There's an open issue [1], but no resolution yet as it seems.
Sorry about the bad news but sync dev is completely dead. Mozilla is scared of touching that code base. So don't expect any improvements or additions there .
Page shot is fantastic btw. No nonsense clipping in Linux (I use onenote on Windows and would love if shots could be exported outside as easily as they are created)
Once you enable testpilot, you can see the experiments. I think the page opens by itself after enabling. Select page shot and click a couple of buttons on different screens.
Are there a substantial number of macOS users using touchscreens?
EDIT: I don't know how I forgot about pinch to zoom via the trackpad. While my original question did start me down an interesting rabbit hole of touchscreen MacOS, I 100% agree that a lack of smooth pinch to zoom via the trackpad detracts from the overall user experience.
No macOS machines ship with touchscreens, but trackpad gestures are used heavily throughout macOS. I find pinch zooming on the Mac to feel pretty natural.
This feature is essential for mobile screens, and this is not meant to dismiss your concern, but what do you need pinch-to-zoom for on desktop? Everything is already huge and readable on desktop.
Sure, I’ve got a 12.3″ netbook (running Linux), and I don’t see any point in a variable zoom there either. Though I suppose it is 4:3 and hidpi.
Still, even at 768p you get a bespoke layout for your device, since this is literally the most common resolution still (seriously). The pinch-to-zoom on mobile is only useful for the very specific case of viewing unoptimized content (mostly desktop sites) in a comparatively smaller viewport. It’s not even useful on mobile if the website is optimized (sometimes for worse, but still).
It’s a nice to have, but hardly essential. But people are saying it prevents them from switching, so I am curious why.
The linux version of firefox still doesn't even have opengl compositing by default, so I wouldn't hold your breath for hardware decoding any time soon.
Not sure if this is related but my firefox/linux experience with video is also bad:
- tearing all the time (https://en.wikipedia.org/wiki/Screen_tearing)
- Netflix doesn't support HD on linux
- Amazon doesn't support HD on linux (for movies. But shows seem to be 1080p)
Got to say -- the latest releases have been a return to the dark ages of firefox. Constant crashes, tab reloads that crash the browser, distorted graphics, high cpu usage, etc...
v60 on my iMac had random tab freezes all the time on "heavier" sites. Sometimes I'd switch to Facebook's tab and the page would just be white with a loading icon in the center, then maybe 1-2 minutes later it would become responsive again. This happened with multiple sites, too.
> A more consistent user experience: Improvements for dark theme support across the entire Firefox user interface
I know it's a bit petty to focus on this one, but I hope it includes a proper dark new tab. Currently the blinding white flash when I open a new one is painful on the eyes at night.
It still flashes a white screen at you when it's loading a tab that had been unloaded (this happens when you have a restored session and you click on a restored tab for the first time.)
I wish Firefox would have a "great suspender" feature. Memory just gets chewed up with a zillion tabs open. They should time out and free up memory. My only option now is just to close, and reopen after a day.
One issue that affects folks with a zillion tabs is that some extensions add a lot of memory usage to every tab. AdBlock Plus is one offender; uBlock Origin is much lighter weight.
Yeh I'm pretty lightweight on extensions, I use only a couple, and uBlock over Adblock. It's just that sites chew through memory over time, and I'm not going to diagnose each one. Firefox already has the feature built in, when you restart the browser, those tabs don't spin up until you access them. They just need to use that functionality on a timer.
In that case, there are some extensions that sleep tabs, and you can use about:memory to figure out which ones are the leakers. Maybe the Firefox crew could figure out how to build this in, it's definitely a case where Chrome's policy means that websites might not fix their leaks because they don't cause problems in Chrome.
Another pet pieve: try closing the window with the regular session _before_ the window with the private tabs... your session is lost like it was 1999.
As occurs when Windows benevolently dictates a restart.
Great release. I feel like momentum has slowed down since the massive version 57 "Quantum" debut, but I haven't had any problems with Firefox on macOS or Linux since then. Keep it up, Mozilla!
Did anyone else discover the "Good News" voice in Firefox's reader mode text-to-voice? It reads the current page to the tune of "Pomp and Circumstance"!
CPU usage seems lower. Especially on streaming videos. Am I seeing things or is that intended? Nice though, my MBP fans don't spin nearly as much when surfing today.
Mozilla throttles auto-updates for the first week or so to watch for surprise regressions. Firefox Beta and Nightly users are not representative of Release channel users, who often have slower hardware, less RAM, and crashy anti virus software. You can bypass the throttling by opening the About Firefox dialog to force an update check.
Posts on HN don't need to be rolled out slowly to spread out the load a bit and your browser doesn't check updates every few seconds if there's only one expected every few weeks.
I don't know the specifics for Firefox in particular, but update checks are classically staggered over at least a full day if not longer. You don't want every user of your product to hit your download servers at the same time.
I don't think that load on the download servers is an issue now. CDNs do a great job of distribution the load. The concern is more that some bugs (especially GPU related) only show up "in the wild". A slow rollout limits the damage if there is a show-stopping bug in the release.
Debian is using Firefox ESR as a compromise to stability since it is not possible to keep older versions while fixing security bugs. Rust is an issue also for Firefox ESR too (when upgrading from 52 to 60).
Yes, Debian uses ESR by default but usually you could easily install the latest version from backports. In the current cycle this is exceptionally not possible, due to rust packaging issues.
Simply that there's no rustc package in Debian stable at the moment. Hopefully, we'll have one for ESR60, but that won't solve the problem for newer releases of Firefox that will require a newer version.
I would switch to Firefox if I could figure out how to disable smooth scroll. It's enabled by default and requires 3 rotations of the scroll wheel to move an inch down the page.
Open about:config and search for 'wheel'. There are ~50 options for tweaking scrolling, including one to disable smooth scroll and ones to tweak the scroll distance.
Thanks everyone! Setting `general.smoothScroll.mouseWheel` to false and increasing `mousewheel.min_line_scroll_amount` x 4 did the trick. I'll be switching to Firefox for now.
Personally I'd say 1000 no thanks if they implemented that. The scrollbars are part of the application chrome, not content. I should choose how to style them, through my OS, not a website I visit.
Bugs are different, 77790 is about color, 547260 is about CSS styling(+size control). Default scrollbar width is very thick and its color is out of web developer control. It's a pain for developer to make a good admin panel with several scrollable areas. JS-scrolling is not stable for all browsers and CPU-intensive for mobiles.
You can try either Tridactyl[1] or Vim-Vixen[2]. They come pretty close to the Vimperator experience (although with WebExtension limitations).
I'd recommend Tridactyl with native extension though (install the extension and type :installnative), as they've done a really great job re-implementing Vimperator features using a wrapper Python script (e.g. support for .tridactylrc, modifying UI[3], open with external editors, etc.)
Thanks for the tip-offs! I too have been stranded without a decent vimperator replacement for a while. Currently using Saka-Keys but not in love with it, so I'll experiment with these.
And now the dark theme also applies to address bar and hamburger menu which is nice bonus.