I hope it picks up momentum among the broader public - while it can feel like the entirity of HN is on Firefox Nightly, there's a much larger leap to be made in overturning the broadly held 'common sense' view that Chrome is the superior browser.
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.
I guess I was one of the Firefox holdouts for years now. After Chrome came out and the adblocker on it was more than useless (I used it since day 1 of public release) I ditched it for Firefox and never looked back. I only kept Chrome for web development to test across different browsers, or to open a new "session" in another browser. Now that Firefox has containers I really don't care for Chrome in that respect though. I'm glad Mozilla is doing things to put themselves back on the spotlight, they've done some great work over the years.
I primarily use Chrome just for the reason that it has better UI than Firefox on Linux. The developer tools on Firefox is too ugly, they definitely need a more compact design.
Firefox 57 has a new UI ("Photon") that you might like, and the DevTools are seeing significant UI/UX work during their rewrite from XUL to HTML (https://github.com/devtools-html/).
Anyone got a rough ETA for when the CSD stuff will make it into main? (or any other hack to hide title bar in MATE/xfce once hidecaptiontitelbarplus addon breaks? sorry to beat dead-horse topic)
Really? I find chrome’s developer tools very ugly though, with bright and garish colors. Firefox’s is much nicer in my opinion. But the nicest-looking devtools is still Safari’s, even though it is also the slowest, buggiest, and had the least features.
Why, with the ability to write powerful extensions removed it is basically a second Chrome now.
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.
WebExtension Experiments are effectively that escape hatch. They have more or less the same access to the internal APIs as legacy add-ons, with the only restriction being that you can only install them on Nightly and Developer Edition.
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 hate WebExtensions, but Mozilla has at least demonstrated a commitment to improve and expand that API instead of letting it rot like Google has. They seem to be adding essential features to it so I think most of the good extensions will be possible within a few releases.
I still wish they hadn't crammed it down our throats before it was ready, though. Jetpack extensions worked fine.
They unfortunately sort of had to rush it. They needed to deprecate legacy extensions, because the majority of those are multiprocess-incompatible and they needed multiprocess to stop the bleeding of users.
If course it was. But there a couple of addons (for me just VimFX) that are going to require full control anyways.
Also it seems to not have done much as basically every extension just asks for full access to every page, but I guess that some don't is an improvement.
Most legacy extensions should already be broken on Nightly, are they not?
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.
> Most legacy extensions should already be broken on Nightly, are they not?
Yes, a lot would be. However if they could still be used many of them would have been fixed by now.
> The majority of legacy extensions are not multiprocess-compatible
Yet many are.
My point is basically that I would like if FF supported the legacy "API" and left the community to manage fixing things that were broken. I would take this work over not being able to have some extensions any day.
I can understand your point of view, but I do think it is very much necessary to cut things off completely.
Otherwise you'd have tons of extensions that could be rewritten as WebExtensions but aren't, because it's less work in the short-term to just fix them for the XUL changes. In the long-term, however, it would be a lot more work, especially if Mozilla starts recklessly breaking things.
Similarly, many unmaintained extensions will disappear and WebExtensions will be written to replace them. Those will almost certainly have better quality and performance. Shouldn't be all too hard to pull off for an unmaintained extension.
And then there's also stories like with NoScript's transition, which very much is a lot of work, but it will leave the NoScript maintainer with a much cleaner code base, not just from the WebExtension API being cleaner, but also simply because he rearchitectured the whole thing, as he was forced to rewrite anyways.
And he'll get significantly better performance out of this, too.
He would not have done a rewrite without this, but he's glad that he did it.
I see the desire to move most extensions. One hope I have is that the next release will roll back some restrictions once active extensions have been ported.
However even if the WebExtensions had an "escape hatch" to browser internals it would still require significant porting effort and the promise of being marked as "Full Browser Access" and "Likely to Break" would probably convince everyone who can to port anyways.
>> but removing the raw access is removing what made Firefox great in the first place.
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.
> 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.
This is simply not true as evidenced by the fact that Nightly still has the legacy extension API and the improved performance.
That being said FF was slowing down to keep extensions compatible. This is why I think WebExtensions are a good idea. They should be the recomended path with promised future compatibility. Then FF can not worry as much about refactoring the internals as there are fewer extensions that would be broken and they "signed up" for it.
I would rather have a faster FF and have to patch VimFX every couple of releases then have FF show down development for fear of breaking things. That being said loosing the extensions that gave FF it's magic is not a good tradeoff in my opinion.
Hmm, I've been using it since if was Phoenix(?), version 0.7 or so IIRC.
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 think they had to make the tough call of breaking compatibility in order to move faster.
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.
I like new Firefox but if Firefox is removing search bar than address bar should take over all functionality from search bar and it doesn't.In search bar there is easy way to add new search engine with + sign and in address bar there isn't.
People tend to assume that if Firefox 57 or other version will be faster then Chrome, then a lot people would then start to use Firefox instead of Chrome.
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 had a few times in past years when I got so irritated by sluggishness of Firefox that I moved to Chromium, despite of the completely unusable tab UI it has when compared to Firefox's (even without addons). Well, it always turned out that Chromium with 8GB RAM and my browsing habits is even worse, so I returned back to Firefox, but if I had 16 or 32GB of RAM it might have turned out to be a different story.
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.
I wouldn't be that pessimistic. The key difference is that Firefox used to have a lot of market share that it lost to Chrome, whereas Opera never really had any to begin with.
These are stupid benchmarks and chrome devs stopped optimizing after them [1] because they don't matter. Michael (the phoronix guy) makes a living out of automating benchmarks and automated feed aggregation (or mailing lists) and those benchmarks especially add nothing of value to the Browser speed discussion.
Can anyone tell me how secure web browsers are on linux generally. I was looking at the pwn2own results and was quite impressed with the edge compromise that got out of the host OS it was running in. However, I didn't see any web browsers on linux being compromised - is that because it is harder, or no-one bothered?
Comparable to Windows. Windows is a high-profile target for web browsing so you're seeing more exploits.
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.
Chrome disables all win32k syscalls in its renderer/extension/plugin processes (at the very least flash and pdf). This has been the default for a while now.
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).
Back when grsecurity was still public I would've said that using it with Chrome provided the best security you could get on Linux. Between the defensive mitigations it added through PaX and all the other little things (like making chroots actually behave like jails) it greatly increased security. This is without even using any MAC system.
I'm not entirely sure how things stack up now. In the past I never had much faith in the vanilla linux kernel.
I feel like I should point out that Firefox won't be getting backported to Debian stable[1]. Until the next Debian stable, it seems that Firefox ESR 52 will be the only version of Firefox.
I downloaded Firefox from mozilla.org and configured a ~/.local/share/applications/firefox.desktop file so that it appears in the GNOME Shell menu. It auto-updates and works great.
Normally, yes. However, something on that page concerns me:
"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.
"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.
IIRC they plan to deploy the Quantum enhancements on Android but it may lag a few versions behind their availability on Desktop since they don't want to have to include both the Quantum and non-Quantum codepaths (so the Quantum changes could be disabled in case bugs turn up) which would bloat their APK size (they try to keep it as small as possible since many Android devices have very little on-board storage).
There's a planned Photon redesign that already landed in Nightly on Android, but, if I remember correctly, it won't make it on time for 57 desktop version (probably around 58 mark). I am not familiar with the other improvements.
Disclaimer: Affiliated with Mozilla, but not with the Firefox team.
> We could not block the web content rendering entirely from reading the filesystem because Firefox still uses GTK directly - we draw webpage HTML widgets using the same theming as the native desktop.
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.
> 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:
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.
Webrender works like the rendering logic of a game engine. The input-handling logic of SDL and friends are badly impoverished compared to what full-blown GUI toolkits support; input methods, accessibility, multiple windows, tooltips, modal dialogs, etc. are all things the GUI toolkit takes care of.
It would be easier to simply build a Qt version of the bits that depend on GTK, so Linux users can choose between those two. But considering how little Firefox seems to care about Linux user experience (FF has been broken with transparent GTK themes since forever and nobody cares; FF removed Linux native audio support and nobody cares), I doubt this will happen and I doubt a patch would be accepted upstream for reasons of "maintenance overhead". This ignores that maintenance overhead is much higher when two independent parties have to maintain the upstream and a patchset, but is for some reason accepted practice in the open-source world.
> FF removed Linux native audio support and nobody cares
No, they didn't. I'm listening to Soundcloud in my Firefox right now; it's sending sound to PulseAudio just fine.
What you actually meant to say is that Firefox removed support for those 1% of Linux users (i.e. 0.01% of total users) that don't have PulseAudio for whatever reason.
Linux's native audio API is ALSA; consult the kernel sources if you don't believe me. Pulse is a common userspace audio system, but is not the native Linux audio API.
Which doesn't mean Firefox should support the kernel API directly, or every audio system out there. And other systems probably have wrappers for PulseAudio API.
I don't fully understand this, but I think this is a lot more complicated than it might seem. Because well, you'd first of all need to set up a separate Gecko instance to render the UI, which isn't fundamentally different from what they're doing with tabs, but still an architectural change.
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.
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.)
I have to say though, having chrome that is virtually indistinguishable from a webpage is a phisher's dream. You also lose 25 years of low-level graphic development in platform toolkits, which likely means losing a lot of performance.
The alternative would be maintaining many toolkit backends. We already see how well that worked out. Qt backend wasn't maintained in a while, and fell into bit rot. That basically prevents Firefox from being used Plasma Mobile and the like. Having HTML backend is better than having none at all.
> I have to say though, having chrome that is virtually indistinguishable from a webpage is a phisher's dream.
That's not terribly hard to do today either. That's why browsers implemented those obnoxious fullscreen animations and notifications somewhen last year.
Firefox OS - IIRC, it rendered the entire UI using HTML drawing directly to the screen using Open GL ES with no 'native' toolkit to speak of, nor requiring any X11 or Wayland backend.
Fennec used to work without GTK? And Firefox on Android does, but there it's probably using another toolkit. It causes this exact problem - porting Firefox to a new system is impossible without rewriting all that.
Yeah, Android Firefox uses the native Android UI toolkit. A long time ago, they had it in XUL, which allowed for some really nice customization and just in general a more conform behaviour with the desktop browser, but performance back then was really just terrible, so that's why they changed it to the native Android UI toolkit.
Interesting; do you know which distros do that? I know Nokia started the Qt stuff (for Maemo), but wasn't aware that anybody was continuing to maintain it. But I haven't looked at things at a level that would have let me know in quite a while.
SailfishOS developers were dragging it along, but after Mozilla dropped support for IPC Embedlite[1] (they never even accepted it officially), I think they got stuck with outdated Gecko. No idea what they are doing about it.
Not WebExtensions (which are the only kind of extension allowed on Firefox 57+ unless you change another pref).
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 :)
You also need an environment variable to be set for it to work.
But yes, it seems to be something you can flip in production. The argument being that if you're in a position to flip prefs you already can break security in a million ways. It's not something you can accidentally flip either.
(The pref doesn't actually "let viruses take over the computer", it just turns off all the security checks)
It doesn't even turn off "all the security checks". It does make it so that certain APIs that let you do all sorts of stuff web content can't normally do are exposed.
It's unlikely to be abused by am attacker, if it requires starting Firefox with a certain environment variable.
Chrome has the same thing with a command line switch.
Useful for some internal unit/integration tests for release and test builds, but really dangerous when pointed to the web.
Actually, "all the security checks" is inaccurate; it seems to enable certain special powers in JS. It turns off one security measure. These special powers seem to be enough to compromise other stuff; but again, if you're in a position to flip that switch you already can compromise other stuff.
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.
I've not been inclined to use this browser since they started with pocket, moved to offering a voice and video chat service, forced PulseAudio as a mandatory dependency and eventually enacted mandatory opt-in telemetry in the browser.
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.
