Great to see Mozilla consistently improving devtools in Firefox. I have been using them over Chrome for a while now, hope it gets to a place where most devs start using FF again for debugging web apps.
It is somewhat newer than mainstream, does not require to enter "yes I'm sure" when opening the dev console and has actually a beta qualifier as version number. I haven't run into any stability issues though.
They have some experimental features enabled there which they don't in other channels.
For example, I'm running Nightly, and the Dev Tools>What's New tab says the "Debug Variables with Watchpoints" (break when a property is read/written) feature is in Developer Edition (and presumably not in Nightly or the Release channel).
> DevTools’ Network panel can now inspect WebSocket messages and automatically formats a variety of framework formats
Finally! This was the main reason to develop on Chrome instead of FF for me. The rest is almost comparable with Chrome DevTools for everyday web development.
The CSS Changes page is a godsend. When editing CSS live it collects all the changes you've made so you can then go back and apply them in your codebase without having to hunt for them in the page elements.
Firefox is wonderful! Still hoping for much-needed general UI improvements, though. The tabs look bulky and have animation performance issues. The bookmarks manager is outdated and inconsistent with other tools in its look. Same with the downloads manager. All these things aren't a big deal, but Safari and Chrome seem to have a more pleasant overall graphic design.
was trying to find a bookmark recently, and seems I have 2 or 3 separate bookmarking systems, some here, some there, some from the menu bar, some from an icon.
Doesn't constantly changing the tab size violate Fitts's Law? I'm sure Google did some sort of study on this, but it seems to me that Chrome's shrinking tabs break a fundamental model of usability. I personally find this problematic not only because the target area shrinks, but also because I can no longer read anything on the tab, so I'm forced to hover over them.
I'd love to read any study on the usability of the Chrome approach if anyone happens to know of one. Maybe something on SIGCHI?
Your assumption of what Fitts's Law is isn't quite correct. Wikipedia has a description of Fitts's Law [1], some of the follow-on work in that space, and its application to HCI. There's a multitude of books, papers, and blog posts that deal with the application of Fitts's law to UI design and usability, so I'll let you pick your favorite source and go with that.
In broad strokes, the time to accurately complete a task is proportional to the distance to an item and inversely proportional to the size of the item. So, having to scroll tabs increases the distance -- potentially a lot. But, constantly shrinking tabs reduces the target size. I think you'd have to do an amortized analysis on this one because upon a the creation of a new tab the Firefox model only makes that new tab harder to get to, while the Chrome model shrinks all tabs, making each harder to click.
But, I could buy that there's some threshold here where Chrome maintains a tab size that still doesn't appreciably increase error rate while improving distance by eliminating the tab scroll. I'd expect that minimal tab width to be much larger than Chrome's true minimum tab width. But, I'd be shocked if Google didn't run usability studies on this. I just haven't come across anything on my own.
Based on my own experience, I think Chrome hits the nail on the head because usually the only helpful thing in terms of finding the right tab is (1) the favicon and (2) the general position of the tab among the other tabs.
General position is particularly helpful because, from left to right, it roughly represents "time opened", earliest to latest.
Firefox doesn't help me find the right tab just by including an 8 character width along with the favicon. Might as well just get rid of those 8 characters.
The shrinking behavior infuriates a lot of people too, by making it impossible to find the tab you want. That's my experience with Chrome, at least.
Setting the "browser.tabs.tabMinWidth" preference to 0 in Firefox will let the tabs shrink down fairly small (to just the favicon and maybe one letter of the title). If you want the tabs to shrink even more than that, I'd like to understand why, other than "it's what I'm used to". Which, to be clear, is a perfectly valid reason to want something!
There should really just be a "Chrome" config template for Firefox for people that prefer Chrome UX and styling.
But in general, it's very upsetting that Firefox doesn't actively support editing these user setting fields.
My experience was that if you changed even a single boolean value, the answer to every support question was "reset to default settings and see if it's still broken". Just awful.
If you have so many tabs they don't fit on the top, just install Tree-Style Tabs extension. It puts tabs to the side panel, and organizes them as a tree.
If a killer, life-changing extension exists in Firefox which is not available on Chrome, this is that extension.
I tried it for a while, but honestly, the UI for tree-style was ugly. If I'm going to look at and interact with something for hours on end, I can't have it be ugly.
Instead they seem to be making the UI worse. The new about:config seems to be a step backwards relative to the old text one (I particularly like that you cannot just browse, you have to know what you're looking for first).
Now if they could focus on native video decoding in Linux, something that actually works with Chromium and leads me to believe that Chromium developers are more committed to open source.
Mozilla are working on a "Wayland DMABuf" feature which will allow for separate processes to share GPU buffers on Linux[1]. For a long time that has been a blocker for hardware-accelerated video decoding as otherwise the data would need to be copied GPU->CPU->GPU which would negate a large portion of the gains. In the short term the work will only apply to WebGL rendering but it should open the door to hardware-accelerated video decoding in the near future.
Previously, "[f]or patent reasons, Firefox [did] not directly support MP3; instead, platform-native libraries [were] used to support MP3."[0] Now it uses ffvpx, which is their fork of ffmpeg. [1] [2]
I switch to Firefox few months ago on macOS and Linux. Other than issues on Youtube video playback ( sometimes the frame just freeze when I switch between different workspace in macOS )and a few minor bugs across google's service the overall experience is mostly on par with Chrome.
I've been shocked by how helpful the new Picture-in-Picture feature is. I wish the pop-out brought the full set of playback controls with it, but it's still far superior to making a full-blown window for video playback.
Its in 71 on macOS (and maybe Linux), but its disabled by default. In about:config, search for picture-in-picture, and enable everything except for always-show (unless you want that). If you right-click a video, there will be a new picture-in-picture option. For Youtube, you need to double-right-click to bring up Firefox's right-click menu.
Can confirm that these options exist and appear to work in linux, at least for me. (ubuntu 16.04)
And im still on v70, so i guess its been there for a little while at least.
It's an interesting. In Chrome the way you can drag tabs out of the window and easily arrange youtube-tabs on the screen while they play works much smoother than in FF. But this new FF approach is kind of another way of solving that problem.
Sadly it's less than useful on MacOS (Still not stable, you have to manually turn it on in about:config). You cannot resize it, and it doesn't stay on top.
I'll update, because that's the sensible thing to do. But, frankly, I only use FF because the Zotero plugin works in it, but not in Safari.
And I tend to load FF, use it for a few minutes, and then quit it. That's because FF has a habit of going nuts somehow, and gulping energy on my OSX systems. I've no idea what causes the problem, and I don't really care, because Safari tends to be faster -- sometimes a lot faster.
FF still causes considerable grief on my wife’s Windows 10 laptop. Two hour battery life is not acceptable. MS Edge (spit) more than triples that battery life.
60 comments
[ 2.8 ms ] story [ 117 ms ] threadFor example, I'm running Nightly, and the Dev Tools>What's New tab says the "Debug Variables with Watchpoints" (break when a property is read/written) feature is in Developer Edition (and presumably not in Nightly or the Release channel).
http://www.mozilla.org/firefox/developer/
Finally! This was the main reason to develop on Chrome instead of FF for me. The rest is almost comparable with Chrome DevTools for everyday web development.
The fact that the tabs don't shrink, but instead slide out of view is infuriating. Something like this affects users constantly.
I'd love to read any study on the usability of the Chrome approach if anyone happens to know of one. Maybe something on SIGCHI?
In that case, I think Firefox violates this. Your tabs are just gone when you could have sworn they were there a second ago...
In broad strokes, the time to accurately complete a task is proportional to the distance to an item and inversely proportional to the size of the item. So, having to scroll tabs increases the distance -- potentially a lot. But, constantly shrinking tabs reduces the target size. I think you'd have to do an amortized analysis on this one because upon a the creation of a new tab the Firefox model only makes that new tab harder to get to, while the Chrome model shrinks all tabs, making each harder to click.
But, I could buy that there's some threshold here where Chrome maintains a tab size that still doesn't appreciably increase error rate while improving distance by eliminating the tab scroll. I'd expect that minimal tab width to be much larger than Chrome's true minimum tab width. But, I'd be shocked if Google didn't run usability studies on this. I just haven't come across anything on my own.
[1] -- https://en.wikipedia.org/wiki/Fitts%27s_law
General position is particularly helpful because, from left to right, it roughly represents "time opened", earliest to latest.
Firefox doesn't help me find the right tab just by including an 8 character width along with the favicon. Might as well just get rid of those 8 characters.
Safari used to have fixed size tabs as well back in the days of yore, I still miss those.
Setting the "browser.tabs.tabMinWidth" preference to 0 in Firefox will let the tabs shrink down fairly small (to just the favicon and maybe one letter of the title). If you want the tabs to shrink even more than that, I'd like to understand why, other than "it's what I'm used to". Which, to be clear, is a perfectly valid reason to want something!
But in general, it's very upsetting that Firefox doesn't actively support editing these user setting fields.
My experience was that if you changed even a single boolean value, the answer to every support question was "reset to default settings and see if it's still broken". Just awful.
If a killer, life-changing extension exists in Firefox which is not available on Chrome, this is that extension.
I can see how I missed it, they made a clickable link/button the same color and style as the other non-clickable text: https://i.imgur.com/gqlCVRo.png
What does "native" mean in this context? Uses accelerated CPU instructions? Uses the codecs of the system instead of something Firefox has built-in?
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1572697
[1] https://code.videolan.org/videolan/libplacebo
[0] https://developer.mozilla.org/en-US/docs/Web/Media/Formats/A...
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1582271
[2] https://github.com/mozilla/gecko-dev/blob/master/media/ffvpx...
https://blog.mozilla.org/blog/2019/12/03/news-from-firefox-o...
And I tend to load FF, use it for a few minutes, and then quit it. That's because FF has a habit of going nuts somehow, and gulping energy on my OSX systems. I've no idea what causes the problem, and I don't really care, because Safari tends to be faster -- sometimes a lot faster.