I don't doubt that such a sea change in public consensus is possible - it happened several years ago with the surge of Chrome in about 2010 [1]. Chrome was markedly quicker than the competition in its day, but I believe that Firefox 57 makes at least as big a performance leap in day-to-day usage over its rivals as Chrome did when it came to prominence. For much of the last ten years, Chrome has been the go-to browser for the tech-saavy user - Firefox is now as well placed as it could ever be to reclaim that crown.
[1] https://commons.wikimedia.org/wiki/File:Browser_usage_share,...
I think WebExtensions were a good idea, but removing the raw access is removing what made Firefox great in the first place. Hopefully they will add an escape hatch in a future release but I'm not holding my breath. I wonder how long staying on nightly will allow "legacy" extensions.
But sure, a bit of performance is nice I guess.
The intent is to have a way to prototype new WebExtension APIs (like hiding individual tabs, or the entire tab bar, or new theme APIs), but there's no requirement that they ever get merged upstream. You're welcome to build and distribute your own for whatever purpose you might want.
I still wish they hadn't crammed it down our throats before it was ready, though. Jetpack extensions worked fine.
No. Firefox's WebExtensions API already offers more than Chrome's does (see webRequest as an example: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/AP...) and more APIs will be added over time to enable more features.
https://palant.de/2017/11/11/on-web-extensions-shortcomings-...
They've refactored tons of code under the hood, basically all the changes that they've wanted to do for years but couldn't do, because it would have broken too many extensions over and over.
We're also talking about all the performance improvements that were made since Firefox 48. The majority of legacy extensions are not multiprocess-compatible and they would not have rolled out multiprocess in 48, if they wouldn't have known those multiprocess-incompatible extensions to be deprecated now with 57. Otherwise AMO would have basically been reverse Russian Roulette, where only roughly 1 out of 6 extensions will not kill your performance.
The raw access is also what made Firefox slow and cumbersome compared to Chrome. The recent performance improvements would have been impossible with the legacy extension apis.
Honesty I think this is a good move.
[0] Step-0 of https://iotdarwinaward.com/post/improve-your-privacy-in-age-...
I'm not convinced they're going in the right direction. Annoying dicking around adding new stuff as default that should be extensions (ones you can remove, and that you choose to add). Then in FF56 on Kubuntu I've noticed a slow down, a lot of lagging for me; but much worse most of [18/20] the add-ons I use are now "legacy" which gives a sense of foreboding that I'll be left choosing long established add-ons _xor_ bugfix/security updates.
We'll see of course, perhaps I'm just getting a little too cynical having been browsing since the days Lynx, Mosaic and Netscape were new tech.
I understand that a lot of devs and power users are annoyed but hopefully we're not the only target audience, we just happen to be a quite vocal in places like HN.
Is there a way to build Firefox without GTK? For example for something like Plasma Mobile? It would be good if there was some fallback mode where Firefox would render UI elements using HTML itself, without relying on UI toolkits.
This isn't quite a meaningful assertion. The way it works in Firefox is that a UI developer specifies in a xul or html document that there should be a button:
<button id="myButton" label="Click me!"/>
Note in particular the `-moz-appearance: button;`. This tells the rendering engine to figure out how big the button is, ask the OS to draw a button of that dimension, and then composite the OS button on top of the button node. I'm not an expert but a quick glance at the code points me to https://dxr.mozilla.org/mozilla-central/source/widget/gtk/ns..., which seems to be the main entry point for Gecko to ask for a widget to be rendered.
As you can see, Firefox does not rely on a toolkit to tell it how buttons _work_, only how they _look_. You could supply a stylesheet that overrides the -moz-appearance rules and you'll get buttons that are rendered purely by Firefox. (You might need to supply some more style rules so that they actually look like buttons.)
If you want to compile without GTK, that's a little more complicated. Firefox uses the toolkit for things like the message loop, mouse and keyboard event processing, etc. You could do all of that in straight Xlib, but who would want to? Certainly nobody has wanted to enough that they've been maintaining an Xlib port all of these years.
Since Webrender is designed like a game engine, may be it should use SDL or something of that sort.
Well, and then you'd probably run into security restrictions, as under normal circumstances, you don't ever want something from inside Gecko to communicate with extensions and probably other things, but for this you need that capability.
Having said that, Mozilla is actually exploring into this direction: https://github.com/browserhtml/browserhtml/blob/master/READM...
And presumably, this is the future, as it would also allow them to get rid of the XUL UI Toolkit, meaning they can entirely focus on core browser technologies. (Which is something different from the XUL/XPCOM extension API that they're deprecating on Tuesday.)
Browser.html is an experiment in that idea for Servo:
https://github.com/browserhtml/browserhtml
If it works out it may end up in Firefox in the long term.
I guess there's a price in each choice.
"Jessie and Stretch backports of Firefox release and beta are gone because of the requirement of rust to build them, which is not available in Jessie or Stretch. Please update your apt sources to use Firefox ESR instead."
I'm not sure how that Rust requirement and ESR 59 will play together; I'll assume they won't play together very well.
Debian is providing Firefox ESR 52 even in oldstable (check security upgrades) https://tracker.debian.org/pkg/firefox-esr
"won't" is a strong claim especially considered you didn't provide any source to back it. The page you've linked doesn't talk about such a possibility at all. This is only your wild guess right now.
Web browser escapes usually target the operating system kernel in order to break out of the sandbox. Chrome can reduce its attack surface on Linux using seccomp, and while there's a win32 syscall filter on Windows 10, I'm not sure if Chrome uses it. Windows has stronger kernel self protection features than Linux, but also more attack surface.
Chrome uses Linux namespaces (like LXC/Docker/...) for isolation in addition to seccomp-bpf.
Chrome is by far the most secure one right now, but as evidenced by this blog article, Firefox is catching up.
I believe the specific win32k syscall filter you're referring to (where you can white/black list specific syscalls) is still only accessible to Microsoft applications (Edge uses it).
I'm not entirely sure how things stack up now. In the past I never had much faith in the vanilla linux kernel.
As much as I would like to see that its not gonna happen, and I am writing this as a Firefox user.
Remember what 'REAL' Opera 12 did in its times comparing to Chrome or Firefox? It loaded pages faster, used less memory, was most standards compliant and also came with bundled torrent client, and mail client and RSS client and ... and having 100+ tabs opened DID NOT EVEN SLOWED IT!
... and guess what, both Firefox and Chrome had more users while Opera had about 4-5%.
It did not mattered if it was faster or better.
Currently Opera is just a Chrome with different skin, so I moved to Firefox with Midori and Iridium as 'backups'.
I'm so glad Firefox catches up. Instead of thinking "I wish Chromium had better UI and I had more RAM", I can just be happy with my browser, embracing my workflow instead of trying to adapt it to the available tools.
Well, for now it is still much slower than Chrome https://www.phoronix.com/scan.php?page=article&item=firefox-...
https://v8project.blogspot.de/2017/04/retiring-octane.html?m...
Disclaimer: Affiliated with Mozilla, but not with the Firefox team.
security.sandbox.content.read_path_whitelist
I mean, Firefox even has a `security.turn_off_all_security_so_that_viruses_can_take_over_this_computer` pref (used in testing; you won't see it in about:config but IIRC you can manually add it. Don't.). Prefs that break security are not new :)
Defense in depth concept is not new either.
The standard way to access files for extensions seems to be with Native Messaging: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Na...
Basically make the user install a small program on their PC, then your extension talks to that program, the program reads out the file that you need and then hands it back to your extension.
sandboxing is great, but if the site is spooky enough im just going to load it in elinks/lynx and grok the text. Chromium also has sandboxing, and if youre really paranoid enough, surf from suckless.org is a webkit style do-it-yourself browser thats fairly reliable.