I'm glad you like it. This is one of those personal UX preferences that has you either one or the other camp. Am I right to assume you liked this from your past Opera use?
I was excited to sudden see this surprise in the patch notes, now I am the opposite here thinking, "How did they mess up such a simple feature?" The preview bar that pop ups is slow to work and actively delays changing tabs.(If it even attempts to switches tabs.) Additionally, I do not need the preview portion.
I'm with you and cannot stand the way Opera does it but it also has a quick tab switching mode. I haven't encountered a single switch-with-preview implementation that didn't leave me with forced slowdown and delay of the action I was about to do. I also configure Firefox to not close the window when it's the last tab, which is hard-to-impossible to emulate in Chrome but is the default in Opera and Vivaldi.
Did something change in font rendering with Freetype on Linux? While 49.0.2 with FreeType 2.7 looked the best (subjectively) I've seen any font rendering (including Windows 10 and OS X Snow Leopard (been a while)), something off with 50.0's rendering. I haven't enabled any custom render options, just your typical archlinux freetype 2.7 desktop. Time to get ESR and compare with that but would be great to hear back from others with a similar environment.
I love 2.7's rendering engine and 49.0.2 looked great, but 50.0 looks washed out. Tried ESR 45.5.0 and it looks great again. I'm confused as to what may have happened from 49 to 50 that caused this.
Built 50.0 with cairo-gtk2 backend using it right now but something different with the font rendering in 50.0. For instance there's a weird washed-out effect of the text in this very same text control I'm writing the comment in which comes and goes with the amount of text changing/wrapping etc.
I think I figured it out. Somehow Skia was enabled in Firefox and resetting that seems to have fixed the rendering bug. Given that 51 will turn Skia on by default I hope this will be fixed before the switch.
For the same reason they haven't made 64-bit the default on Windows and provide two versions. There are many users for whom only one variant works reliably. If upstream, like in the case of cairo-gtk3, decides GTK2 is not supported anymore, it's a matter of chance whether your cairo-gtk2 build of Firefox works at all. For instance, for me 49.0.2 gtk2 local build on Arch crashes anytime I try to use the file dialog, while of course the file dialog of both GTK2 and GTK3 doesn't crash in other gtk apps on the same machine.
On windows, Firefox is the main supplier of binaries. I would hazard that on most Linux/BSD systems, the distribution is the main supplier of binaries. The distributions can easily build it as GTK2 if they want, or provide a GTK2 variant (and as pointed out above, some distributions seem to, or at least make it easy to build it yourself).
If you are on Linux and your distribution provides Firefox, this is a complaint to be leveled at your distribution, not Mozilla (who apparently already makes it easy to build the variant). I'm not sure how we got to a position where people feel justified in criticizing a company providing an open source product that's updated often and provides umpteen different binaries for different platforms and different build for those platforms for not building one more special configuration for what it likely a very small group of people, who can easily do so for themselves.
In the past the GTK3 code path was tested only by Red Hat as the primary developer of all things GTK and GNOME. At that time, there was only a GTK2 build from Mozilla, and now instead of doing the same as Windows 32-bit/64-bit we're presented with just GTK3 support with the promise to obsolete the GTK2 code, while seemingly not considering the regressions of GTK3.
Why do we use Mozilla binaries of Firefox on linux distro where there's Firefox builds in the package repository? Many reasons:
1. fast access to security fixes
2. access to EMEfree builds
3. access to different channels
While it is easy to build with cairo-gtk2 as the backend, that code path, as I wrote in a sibling comment, reliably crashes for me anytime I try to do File-Open. I'll try to find out if that AUR recipe or Gentoo ebuild do something different that makes it stable, but the fact remains that GTK2 is about to be unsupported by Mozilla while GTK3 hasn't gotten stable yet, which will make life for anyone that tries to build a GTK2 variant very hard. Therefore, I wouldn't really say it's an easy choice.
> While it is easy to build with cairo-gtk2 as the backend, that code path, as I wrote in a sibling comment, reliably crashes for me anytime I try to do File-Open.
That points towards GTK2 support possibly not being functional, which could be a good reason why they don't provide a build for it, even if they wanted to.
It sounds like the real problem here is that Mozilla is changing stuff that some people don't want changed. I don't think the solution is to ask Mozilla to produce a GTK2 build, but to ask them to fix anything they've broken. If they've decided to move towards GTK3, then that's their choice, and presumably they have reasons for that choice. I don't think it's out of line for them to expect to support a single working build for an architecture/OS combo. That said, they can and should be notified and pressured to fix any regressions. Additionally, if the change is something people don't want, Mozilla should be notified of that (although I suspect there are technical reasons for the change that most people are ignoring).
Good points. Just finished building firefox 50.0 with for cairo-gtk2 and trying it out now. Hope there are no crashes.
I agree with what you say and want to add that there two issues here. First is the GTK3 port of Firefox not working as a native Wayland GTK3 window. Second is the themeing issues with GTK3 that people ran into, which is something you can live with. Finally, it's the serious regressions of GTK3 itself which go unnoticed or ignored as evident in the gnome.org bug-tracker and the tickets I've linked to in a sibling comment.
The most important argument for Mozilla providing GTK2 builds is that otherwise the likelihood of the code bitrotting is very high as it happened with the Qt port. The interesting aspect of the Qt port was that at that point in time GTK2 was the best choice, but now for substantiated reasons major applications chose to rather port to Qt than GTK3. Therefore, if the Qt port were to be revived it's much more likely to be of interest and maintained than back when the GTK2 port was good enough that nobody cared about Qt.
I know X11 and Wayland are not Mozilla's main platforms of interest and I'm grateful that they do support with the feature set they do. I'm surprised at the seemingly isolated echo chamber perspective of the GTK3 devs. It's an interesting behavior to observe since without non-GNOME users it could just as well be rolled into GNOME itself. Interesting times, having lived through the times when jwz in 1998 was debating whether GTK1 was any good for Linux.
> First is the GTK3 port of Firefox not working as a native Wayland GTK3 window.
Is that officially supported yet? I see that back in June/July experimental support was released. Possibly is the current work in an effort to get that working, but it's not ready yet? I just tracked down what looks like the feature tracking bug[1], and it doesn't appear to be ready, but I could be reading it wrong.
> Second is the themeing issues with GTK3 that people ran into, which is something you can live with.
Sure, but from my own problems with themes in Chrome, it's not something you want to live with, especially if you used themes to signify instance information and they stopped working, so I feel people's pain there. :/ Preferably Mozilla would have kept this gated in a branch or experimental build until these issues were worked out. That said, earlier today I did see something about plugins built using GTK2 being loaded into Firefox with GTK3 and the symbols loading wrong, so perhaps it's a much harder problem than it seems, and if it requires theme's to rebuild, then perhaps the quickest and easiest way to make that happen is to force a little breakage. Then again, the distro build probably makes sure this isn't a problem.
> I'm surprised at the seemingly isolated echo chamber perspective of the GTK3 devs.
I imagine that's somewhat to do with where their focus lies. I'm under the impression that a lot of the funding comes from Red Hat, so there are likely complex motives at multiple levels from the enterprise to the funded developers (who might want to justify their paycheck).
In the end, it's one of those things that's hard to accurately critique as an outsider, because there's a lot of specific information that goes into a decision like that. Is a GTK2 to GTK3 migration easier than a GTK2 to QT (or some other toolkit) migration? Probably, but by how much? If this was happening a few years ago, we might be complaining that Firefox uses a toolkit (that is, underneath their own toolkit) instead of X directly. Now we have X and Wayland, so that wouldn't have presented a similar situation anyway. In the end, unless you have some upstream vendor willing to put lots of time and money into making sure you have a performant, backwards compatible API to call (e.g. Microsoft), you'll probably want to make changes at some point in any long-lived project.
The "EME-free" build differs only by the default value for the "Play DRM content" checkbox. You can put a normal build in the equivalent state by unchecking the checkbox.
The "Play DRM content" checkbox controls both the EME API and the automatic download and installation of the DRM blob (the Google Widevine CDM). So you are still correct. :)
FWIW, 64-bit Firefox will be the installer default for new installs (and re-installs) on 64-bit Windows 7/8/8.1/10 starting in Firefox 53. Migrating existing 32-bit Firefox users to 64-bit will probably happen in mid-to-late 2017. Similarly, Google plans to migrate their 32-bit Chrome users to 64-bit sometime in 2017, too.
After almost a decade of building Firefox from source I finally bit the bullet to switch to a precompiled binary last month. It's fixed all the issues that have started to crop up but leaves a bad taste in the mouth.
I had been using their binaries due to security updates and having to build at inopportune times for an hour or three (depending on machine), but like I wrote in a sibling comment, enabling the cairo-gtk2 backend resulted in crashes when trying to select a file with the gtk file dialog. So I bit the bullet and am struggling with the drawing regressions of GTK3.
Also GTK3's file dialog is subjectively a huge regression, but others may prefer it, just like Apple's finder changed over time. I still haven't figured out how dconf and gconf work with GTK3, not using GNOME3 as a desktop.
There are more issues with GTK3 but these are the most visible for those of us who don't use GTK3 regularly as part of GNOME3 and have been forced to use it via Firefox. The way I read the GTK3 bugreport it seems like the devs don't test GTK3 outside GNOME3 and hence do not consider it a priority. That one dev has been stressing that a compositor is needed and multiple answers by the reporter that they're using a compositor seem to be missed during reading on the other side. It's a weird exchange. I'm with the reporter. If GTK3 is not supposed to or not tested outside GNOME3, then this should be communicated so that everyone can make an informed decision to use something else or revive the Firefox Qt toolkit code.
I love GTK2, but I can do without GTK3, seeing we're at 3.22 and it's still not as stable or regression free as GTK2.
I'd be the first to build and use a Firefox where the Qt port was updated and made to work but GTK is the GUI toolkit used by Firefox outside Android, macOS and Windows. That said, GTK2 was and still is very good at what it does. It just works but doesn't support Wayland.
I cannot move to Wayland anyway until xterm or rxvt-unicode are ported since XWayland integration is still imperfect. Like they wrote in the bug report, while GTK2 doesn't have a Wayland backend, GTK3's backend isn't really production quality either with dialogs sometimes opting to zoom out rather than scale out or general stability issues. If you try to start Firefox under Wayland by telling GDK to use Wayland, it just crashes on startup.
