Chrome 62 Promoted To Stable

[Hi-Angel]

While I agree with the above, Firefox was getting behind in the browsers race in an alarming way, I don't think they could afford waiting for so long.

Will be a blood bath, and Mozilla handled the whole thing like total crap by waiting too long to start this conversion, but that's the only way forward currently.

I absolutely don't see how does it help them. It is easy to lose users — just screw them in some way for you're not a monopoly. But getting these users back, or getting new users when they know that old users gone because the company messed with them, is hard. So, what's the plan?

[starshipeleven]

I absolutely don't see how does it help them.

I'll help you: Most of their users don't use extensions, and if the browser runs like crap while on default settings, these users will switch over.
Firefox has been in this state for years, and many people just switched over to Chrome.

Extensions were one of the reasons Firefox kept sucking, devs could not freely change the underlying parts of Firefox without causing massive breakage every release.
WebExtensions API allows extensions to work without going raw and interfacing directly with Firefox's inner workings, and let the devs work on the core functionality without fear of breaking extensions.

Mozilla took way too much time to decide that they really needed to address this, and they are now short on time and have to shaft someone to get back in shape asap. This is where they could have done better.

People using extensions are those that need some functionality, and many will come back once Firefox extends the WebExtensions to add functionality that isn't available on Chrome.

And webextensions allows people to port over Chrome extensions, like https://addons.mozilla.org/en-US/fir...don/vimium-ff/ that is a port of Vimium extension on Chrome.

[Hi-Angel]

People using extensions are those that need some functionality, and many will come back once Firefox extends the WebExtensions to add functionality that isn't available on Chrome.

I guess, once appeared in Firefox, Chrome will add the new functionality too to keep feature parity. Besides, peoples who gone from Firefox because of XUL obsoletion are usually ones who either participated or at least have read those countless discussions; so they know that Mozilla didn't communicate with them in any way, not even in terms of explanation like yours one. Mozilla just gave up on them. And as far as there's alternative, I think many of them will evade Firefox. Because this is how business works: a company don't give a sh*t on you — you don't give a sh*t on that company.

And webextensions allows people to port over Chrome extensions, like https://addons.mozilla.org/en-US/fir...don/vimium-ff/ that is a port of Vimium extension on Chrome.

Vimium is a crap, even in terms of navigation. I know because I tried using it on Chromium; and it won't work any better until this WebExtension bug get solved.

And FTR, Qutebrowser nowadays is a great alternative to Vimperator or Pentadactyl. And this is not "an alternative browser" in a way like 10% sites won't work because of a missing support for something. Because it's based on QtWebEngine, so you can expect it supports everything that Chromium does. Some defaults sucks though.

[starshipeleven]

I guess, once appeared in Firefox, Chrome will add the new functionality too to keep feature parity.

If it does, then it's still win-win.
I'm suspecting they won't, at least not in the web blocking department (i.e. for NoScript)

Besides, peoples who gone from Firefox because of XUL obsoletion are usually ones who either participated or at least have read those countless discussions; so they know that Mozilla didn't communicate with them in any way, not even in terms of explanation like yours one.

Just to provide another data point (I like to call it "more rational", but ymmv):

I've been around enough to know that internal politics in organizations without a strong leadership are messy, and that developers don't excel at communication, so I'm not expecting Mozilla to get their shit together as for example Chromium community (aka google) does.

I just need extension functionality and I'm sure Chrome/ium won't magically add better webextension API without some competition, so Mozilla is the only horse I can bet on.

As long as this is a 1-2 year bump in the road for major extensions like Noscript or the downloader extensions I'm fine. I can keep using FF ESR (the one with extended support) in the meantime or whatever.

And FTR, Qutebrowser nowadays is a great alternative to Vimperator or Pentadactyl. And this is not "an alternative browser" in a way like 10% sites won't work because of a missing support for something. Because it's based on QtWebEngine, so you can expect it supports everything that Chromium does. Some defaults sucks though.

Good to know, will suggest this to the people needing that functionality.

[carewolf]

The patch isn't even checked in yet (see here: https://chromium-review.googlesource...m/src/+/532294), so version 64 at the earliest, but I'd say even later as there doesn't seem to be any rush to review the patch, it's been just sitting there since the beginning of September.

I uploaded a similar patch last year in July. Also not reviewed. Generally Google don't care that much about Linux outside of making it work, optimizing is for Android and ChromeOS.

I did update it yesterday and try it again.. It made a mess out of VP9 movies.. So probably the VAAPI drivers are still not that good, and that was on a Kaby Lake processor with Debian unstable drivers. VP8 and JPEGs looked fine though (my patch also enabled hardware accelerated jpeg decoding). If it requires extensive hardware and driver version testing to make fine grained blacklists, I can understand why Google hesitates.

[carewolf]

Good to know, will suggest this to the people needing that functionality.

Besides Qutebrowser. Qupzilla, or Falkon as the next release will be called, is also a really solid browser now, and it also uses QtWebEngine as the backend. Though for QtWebEngine based browsers, if you use them on Linux, I would recommend building QtWebEngine yourself and enable proprietary-codecs (qmake -- -proprietary-codecs), that way they can play H264/H265 movies, and will even work with Netflix which Chromium does not out of the box.

And note you can always build the newest QtWebEngine even if your distro's Qt version is a bit old, it supports all Qt version back to latest LTS release. If you are stuck with Qt 5.7.1 for instance, you can use QtWebEngine from 5.9.2 and get something based on Chromium 56 with security patches up to Chromium 61 (62 wasn't release yet), instead of being stuck with something Chromum 49 based. And even if there have been no critical security issues recently, there have been plenty of high ones, for instance ways of getting around some cross-site scripting restricting,

[RealNC]

How? Can you elaborate?

Everything has stutter. Scrolling, youtube videos (or any other video site), all stutter. The reason for the stutter becomes clear once you measure the frame rate at which Chrome runs:

https://www.vsynctester.com

The results speak for themselves there. Heavy stutter because Chrome is erratically running at anywhere between 55FPS and 70FPS. It's unable to "lock-on" to 120FPS. It seems the highest refresh rate Chrome is able to lock-on to is 75Hz (it then locks to 75FPS.) But higher refresh rates than that produce crappy results with lots of stutter.

On Windows it's perfect. No stutters anywhere. Chrome is able to synchronize perfectly to 120FPS.

A while back (forgot when; it was around Chrome version 53 or so), 120Hz was working perfectly on Linux too. Then they broke it and never fixed it since.

A thing to note here is that synchronizing correctly to the monitor's refresh rate in order to not stutter is actually part of the HTML spec. Since Chrome doesn't do that on Linux, it actually means Chrome on Linux is not spec compliant.