However, I have two major tab-management issues with Firefox which make it near-unusable for me:
1. No support for "scroll wheel to switch tabs" (scroll on tabs to switch between them). This is a feature common to nearly all Linux software and Firefox removed it a few versions ago. Quantum killed "Tab Wheel Scroll" which reimplemented it.
2. No support for multi-select tab management, which Chrome is amazing with. If you didn't know, in Chrome, you can ctrl+click and shift+click tabs to select multiple at once and close, move or snap all of them at once like in a file manager. Super useful.
Hi; I work on scrolling/rendering in Chrome. Thanks for bringing this to my attention, that is some super janky scrolling in Chrome >_<. I've filed http://crbug.com/786991 for us to look into it.
Some technical background (since this is HN after all); at a quick glance there are two things going wrong here in Chrome.
1. We would normally want to 'composite' the scrolling region here, which means we paint the pixels only once into a saved layer and then just slide that up and down as you scroll. I believe that is not happening on the Stripe page because of the unusual way that they are doing the split-panel background. Looks like we're currently unable to tell that the background is an opaque color, so we can't apply sub-pixel font AA[0] - and on low DPI we will refuse to composite in that case.
2. Chrome's repainting of this page is really slow. :(. Firefox Nightly is also repainting the page when you scroll (as far as I can tell), but they're definitely doing it much faster than Chrome!
So our goal will be to try and figure out how to composite this page, and if that's not possible then we'll have to dig into the slow painting.
Note: Because we composite more readily on high DPI devices (where sub-pixel font AA[0] doesn't matter), this site should scroll nice and fast on a high resolution display. This includes most new laptops, all (?) phones/tablets, etc.
I’m about to go mad because I’ve been reporting bugs in subpixel aliasing under hi-dpi displays with non-standard DPIs (!= 96dpi) for a while but the Chromium QA team in India has been having a hard time triaging them, possibly because of the hi-dpi display requirement.
I’ve also got a fully reproducible issue involving CSS transforms I haven’t bugged yet as I’ve just been struggling to get someone to triage #765848 correctly as of yet:
https://bugs.chromium.org/p/chromium/issues/detail?id=765848
Can you send me an email, pretty please? mqudsi [at] NeoSmart [dot] net
I was experiencing this particular bug on all my hi-dpi machines but it magically went away on one of them (perhaps after an OS update, as it’s running Windows 10 RS4 seeds) but it’s fully reproducible on all my other machines with a clean profile on all channels.
> Note: Because we composite more readily on high DPI devices (where sub-pixel font AA[0] doesn't matter), this site should scroll nice and fast on a high resolution display. This includes most new laptops, all (?) phones/tablets, etc.
Not the case for me. Touchscreen display on a UX asus laptop, 3.2k resolution on linux with intel card. Scrolling using the touchscreen is snappy, scrolling using the scroll wheel (synaptics emulation) is even worse than on my desktop.
Wow you were not exaggerating on that.
There seems to be a new add-on for the web extension approach (https://addons.mozilla.org/en-US/firefox/addon/foxy-gestures...), but I haven't tested it yet and am not sure how robust it is at this point.
Also mouse gestures now have the same annoying "feature" they've always had in Chrome: they don't work in "system" tabs (think about:preferences).
So you can't use mouse gesture to quickly go through opened tabs if at least one of them is the "system" one, the navigation simply dies there.
I don't think they're ever going to fix the "system tabs" issue, since it's supposedly a "feature", but at least some good news. :)
I've yet to find a gesture extension that supports the same rocker gestures (i.e. middle click + other click to change tabs).
Looks like https://bugzilla.mozilla.org/show_bug.cgi?id=566510 tracks the multiselect thing in Firefox and has seen some recent movement... That would indeed be very nice to have!
Yeah I am missing this as well. I switched to Firefox a few days ago after hearing about all the improvements.
So far, three issues:
1- On my MBP, I am having serious issues when I have tabs to recover.
2- HTML5 videos are not hardware accelerated. Neither on OSX, nor on my Arch.
3- Cannot move multiple tabs from one window to another but that actually seems to work better with i3's drag and drop.
The thing that bugged me about the mobile app was that coming from Chrome it didn't seem to have the same level of integration with my phone. For instance I'd google search something, get the result which included a map, and then the map was not clickable. I expected to be able to tap it and have the map open in Google Maps but no. It was a static image.
I had similar experiences with other apps like Twitter, Instagram, and Redfin. I expected a link to the mobile site to launch the installed app on my phone but it never did. I looked around a bit in the settings and couldn't find anything to do it. I'm sure there's a solution for it but I got tired of poking around and went back to what just worked.
https://bugzilla.mozilla.org/show_bug.cgi?id=1418510
VP9 is disabled by default in Firefox on Mac because H.264 can be hardware-accelerated on Mac but VP9 can't. Firefox supports hardware accelerated VP9 on some Windows machines, though.
That's a setback for royalty-free media formats on the web. Is there a plan for VP9 to be enabled by default again in the future?
Not sure if this is something YouTube does or it's a general video playback problem.
I observed it before FF 57 was released, on different Windows computers but especially catastrophic on the less powerful ones ( https://news.ycombinator.com/item?id=15688195 or https://news.ycombinator.com/item?id=15687830, I've mentioned that I also discovered that there are complaints at least since February this year, https://www.reddit.com/r/firefox/comments/5sikxt/firefox_unb... only to be downvoted heavily, however let's ignore that at the moment) but now on FF 57 it is provably the same. Just produce a page with more videos autostarting and marvel how much (unbelievably lot!) CPU Firefox uses.
8 videos playing on the page are enough to demonstrate it. Fascinatingly, even if they play somewhere on the page outside of the part which is currently displayed, and even if they are not producing any sound (marked as such) they are going to eat immense amount of CPU.
The only major complaint I have with Firefox (as of 57) is with openh264. It grabs a whole CPU core for a video that Safari handles at a fourth of that or less.
There shouldn't be much difference for h264 videos between Safari and Firefox, except in Full Screen. For full screen, Safari uses the OS to render the images and can have a very efficient code path. Firefox doesn't support it at all (for now)
I find my web browsing experience on Os X quite bad overall.
Firefox still does not support VAAPI or VDPAU :(
Firefox doesn't use a blacklist of drivers / GPU like it does on window to enable HW decoding or not. Typically mac hardware is far more reliable.
the media.hardware-video-decoding.force-enabled is only of use on Windows in the event a card is blacklisted and you want to override the blacklist
Unfortunately 3rd party browsers are at a disadvantage because it is harder to automatically detect and use video acceleration hardware capabilities.
https://developer.apple.com/library/content/technotes/tn2267...
The VDADecoderCreate function will return an error if HW video decoding isn't available.
Equivalent features are provided in the Video Toolbox framework from OS X 10.8 and later.
Firefox only supports 10.9 and later from now on, and no longer uses VDA.
Unlike VDA, when you create a decoder, you just get one. You then query if it's a hardware decoder or not, but the behaviour is fundamentally the same between SW and HW.
For some reasons, the VT frame gives us a software decoder most of the time for some users.
Until now, I had only ever seen Mac Pro (including 2013 trashcan model) to not provide hardware decoding support.
If you attempt to decode a video that is less than 144 pixels high, you always get a software decoder.
My experience for 3 major browsers on MacOS as follows:
- If you want noticeably longer battery life when on the travel.
1- Safari
2- Chrome/Firefox
- If you want seamless browsing experience.
1- Chrome
2- Firefox
3- Safari