Originally posted by starshipeleven
View Post
Announcement
Collapse
No announcement yet.
Chrome 62 Promoted To Stable
Collapse
X
-
- Likes 1
-
Originally posted by Hi-Angel View PostI absolutely don't see how does it help them.
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.
Comment
-
Originally posted by starshipeleven View PostPeople 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.
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.
- Likes 1
Comment
-
Originally posted by Hi-Angel View PostI guess, once appeared in Firefox, Chrome will add the new functionality too to keep feature parity.
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.
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.
Comment
-
Originally posted by Gusar View PostThe 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 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.
- Likes 1
Comment
-
Originally posted by starshipeleven View PostGood to know, will suggest this to the people needing that functionality.
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,
- Likes 1
Comment
-
Originally posted by leipero View Post
How? Can you elaborate?
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.Last edited by RealNC; 22 October 2017, 03:54 AM.
Comment
Comment