Changes To Look Forward To With Firefox 52

[Hibbelharry]

You are missing the point of my post. TP-Link was (AFAIK) the only manufacturer of IP cameras to choose the opensource way to show video of their cameras in a web browser. And they got burned for it. The funny thing is, if they used a Internet Explorer plugin, like all the other companies, they didn't have to worry about any API breakage. But they choose opensource, and the opensource guys left they hanging.

TP-Link provides 5 years of firmware support for they products, witch is more than some other multibillionaire companies do (coff "Google Nexus devices" coff), and the camera I have is more that 5 years old. I choose it because it was the only manufacturer that allowed you to use all its features in Linux, without any IE crap. You still could see and operate it trough other protocols, like OVINF. There are several Android apps for that, and my NVR is using it. The only thing that will stop work is the browser video plugin, although you still can see the feed trough JPEG images, but that's inferior than the VLC plugin.

Mozilla isn't the only one here to blame, Google dropped the ball earlier too. But the message is the same: if you are a hardware manufacturer, you cannot thrust then to base your product features better than Microsoft, and to me this is a very bad message from the opensource guys.

You didn't notice MS dropping IE and ActiveX, too? IE11 is currently still there, beeing an optional addon, hidden deep in the Startmenu. But the future way to go if you believe MS is MS Edge, not supporting ActiveX.

[LinAGKar]

It's not. You can go to about:support to check multi-threading status. Some addons are incompatible with multi-threading (you can check status for many plugins here: https://arewee10syet.com/). If FF detects an incompatible add-on, if will turn off multi-threading rather than letting the browser/add-on misbehave, but there's a way to force multi-threading on, too.
And afaik, there are plans to parallelize additional things in the future.

That's not multi-threading, that's multi-process, where the content is run in a separate process from the chrome. It has nothing to do with multi-threaded JS.

[[email protected]]

WebRTC is the safe, standardized way of sending A/V streams to a browser, Firefox and Chrome have supported it for over two years and it's coming to Edge and Safari too. If TP-Link can't update its platforms to use standardized methods then their software support is mediocre at best.

You are missing the point of my post. TP-Link was (AFAIK) the only manufacturer of IP cameras to choose the opensource way to show video of their cameras in a web browser. And they got burned for it. The funny thing is, if they used a Internet Explorer plugin, like all the other companies, they didn't have to worry about any API breakage. But they choose opensource, and the opensource guys left they hanging.

TP-Link provides 5 years of firmware support for they products, witch is more than some other multibillionaire companies do (coff "Google Nexus devices" coff), and the camera I have is more that 5 years old. I choose it because it was the only manufacturer that allowed you to use all its features in Linux, without any IE crap. You still could see and operate it trough other protocols, like OVINF. There are several Android apps for that, and my NVR is using it. The only thing that will stop work is the browser video plugin, although you still can see the feed trough JPEG images, but that's inferior than the VLC plugin.

Mozilla isn't the only one here to blame, Google dropped the ball earlier too. But the message is the same: if you are a hardware manufacturer, you cannot thrust then to base your product features better than Microsoft, and to me this is a very bad message from the opensource guys.

[Nuc!eoN]

it requires to use pulseaudio, uses more ram than Chrome and Google Hangouts does not work. It is garbage software now, used firefox for several years.

There is ongoing work to make OSSv4 natively working as an audio backend

https://bugzilla.mozilla.org/show_bug.cgi?id=1021761

[[email protected]]

Nice rock you've been living under.

Wow, tanks for noticing man!

[Michael_S]

Midori is replaced with gnome-web on elementary OS 0.4 Loki which was released last year. But yeah, it wasn't a good choice if you look at security, stability, features, plugins and extensions, etc...

I like Elementary OS and I run it. They picked Midori first and then Epiphany later because they could more easily re-theme them to work with the Elementary desktop themes, title bar behavior, etc...

I think the team's focus on beautiful aesthetics is admirable. But everything else about Elementary's desktop environment is fast and stable as well as pretty. Midori and Epiphany aren't. The first thing I do on Elementary is install Firefox and Chrome.

[JonathanM]

Great, the forum is eating my posts...

[JonathanM]

@All of those Elementary OS lovers, don't you think it's weird (as in safety) to have Midori as default?

Midori is replaced with gnome-web on elementary OS 0.4 Loki which was released last year. But yeah, it wasn't a good choice if you look at security, stability, features, plugins and extensions, etc...

[bug77]

Is Firefox still running single-threaded? Damn, they need a new JS/HTML engine by yesterday if that's still the case.

I'm still using Firefox as I trust Mozilla more than I trust Google... Google has a massive conflict of interest between selling ads and protecting user privacy.

It's not. You can go to about:support to check multi-threading status. Some addons are incompatible with multi-threading (you can check status for many plugins here: https://arewee10syet.com/). If FF detects an incompatible add-on, if will turn off multi-threading rather than letting the browser/add-on misbehave, but there's a way to force multi-threading on, too.
And afaik, there are plans to parallelize additional things in the future.

[Michael_S]

firefox has to improve hardly providing reliable hardware acceleration as well as to manage effectively both system ram VRam, cpu cache and buffers because it is very slow compared to chrome. It is not able to detect all the system abilities by which to take benefits. On the same hardware chrome is able to feature very well hardware acceleration where firefox fails.

Chrome is faster, but I'm pretty sure your explanation for why is incorrect. The operating system handles using RAM, cache, and buffers efficiently, you don't have to put custom code into your application to do it for you.

You can add custom code, and if you're trying to get absolute maximum performance from a particular piece of hardware you will. Console games typically do, because the game maker knows exactly what hardware the game runs on. But Firefox developers and even Chrome developers can't profile their browser on everything from a Pentium 4 to the latest Atom to the latest i7, the Athlon 64 to the Kabini 5150 to Ryzen, hundreds of different ARM processors, and various RAM limits and optimize for all cases.

The biggest performance advantage Chrome had for a long time was being multi-process while Firefox was single process. Firefox transitioned to partial multi-process in 2016, but a lot of plugins forced it to work in a single process way. But if you're running Firefox 51 or 52 and you have no plugins or all of your plugins are compatible with Firefox multi-process, it's really fast. Anything that Chrome does, Firefox does at the same speed or at most a second slower. I use the Privacy Badger plugin that blocks third party tracking. It transitioned to multi-process in late December, and the difference in Firefox speed for me was instantly noticeable.

Chrome still has more efficient rendering code. The rendering performance gap is large, which is part of the reason the Firefox team is rewriting their rendering engine with Servo. Firefox's Javascript engine has been neck and neck with the one in Chrome for years.