
Firefox 54: E10S-Multi, WebExtension APIs, CSS Clip-Path - petercooper
https://hacks.mozilla.org/2017/06/firefox-54-e10s-webextension-apis-css-clip-path/
======
luhn
I attempted to switch to Firefox earlier this year, as part of a personal
exodus from Google. I ended up switching back to Chrome because I couldn't
tolerate the poor performance.

I'm giving it another shot now that Electrolysis is there. I've only been
using it for half an hour now, but my initial experience has been promising.

~~~
callahad
Welcome back! Fair warning, legacy add-ons can perform _worse_ under multi-
process Firefox, since any synchronous APIs now require cross-process locking.
To the greatest extent possible, try to limit yourself to add-ons badged with
"Compatible with Firefox 57+" on addons.mozilla.org, which are guaranteed work
well under Electrolysis.

Also, get ready for Firefox 57. Just one example, in one benchmark, but the
last data point on the right _is_ accurate:
[https://screenshots.firefox.com/1DYGktRBpiIJBc7T/arewefastye...](https://screenshots.firefox.com/1DYGktRBpiIJBc7T/arewefastyet.com)

~~~
kibwen
What particular change is responsible for the performance improvement seen in
that benchmark? Not anything related to Quantum/Servo surely; I expect those
benchmarks to reflect Javascript performance exclusively, and I haven't heard
anything in a long time from Mozilla regarding Spidermonkey improvements.

~~~
bzbarsky
There's been a steady march of performance improvements in Spidermonkey,
though they haven't gotten very much press. They've been rearchitecting most
of the inline caches so there's more sharing between the baseline and
optimizing compiler and less in the way of performance cliffs. See
[https://bugzilla.mozilla.org/show_bug.cgi?id=1259927](https://bugzilla.mozilla.org/show_bug.cgi?id=1259927)
and its dependencies
([https://bugzilla.mozilla.org/showdependencytree.cgi?id=12599...](https://bugzilla.mozilla.org/showdependencytree.cgi?id=1259927&hide_resolved=0)
for the dependency view). Things like
[https://bugzilla.mozilla.org/show_bug.cgi?id=1328140](https://bugzilla.mozilla.org/show_bug.cgi?id=1328140)
led to significant improvements to the sort of megamorphic code you commonly
see in frameworks (e.g.
[https://bugzilla.mozilla.org/show_bug.cgi?id=1328140#c14](https://bugzilla.mozilla.org/show_bug.cgi?id=1328140#c14)
shows 25% improvements on Ember benchmarks).

This work has been ongoing; a bunch of it landed in 53, more in 54, and more
has been landing since. What makes it a bit harder to advertise is that it's
aiming at reducing performance cliffs and improving the chance that real-life
code lands on fast paths, not on improving the performance of those already-
fast paths. WebAssembly is where the "make the fast bits faster" action is,
mostly.

------
justinmayer
In case you're wondering how this release affects legacy (non-WebExtension)
add-ons, and what the roadmap looks like until Firefox 57 fully disables
legacy add-ons: [https://blog.mozilla.org/addons/2017/02/16/the-road-to-
firef...](https://blog.mozilla.org/addons/2017/02/16/the-road-to-
firefox-57-compatibility-milestones/)

~~~
throwanem
For a more detailed, albeit less well organized, view of functionality yet to
be added to the WebExtensions API, there's also the relevant Bugzilla
whiteboard [1].

The tl;dr: is that, compared to the XUL API, WebExtensions provide a very
limited set of functionality, such that many existing XUL add-ons can't easily
be reimplemented in or ported to the new API. On the other hand, it's early
days yet, and there appears to be a reasonable amount of interest and
developer support devoted to extending the new API so that it offers
capabilities comparable to the old. I'd imagine it'll probably be next year
this time, more or less, before the dust has largely settled.

[1]
[https://bugzilla.mozilla.org/buglist.cgi?f1=status_whiteboar...](https://bugzilla.mozilla.org/buglist.cgi?f1=status_whiteboard&o1=substring&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&v1=%5Bdesign-
decision-
approved%5D&component=WebExtensions%3A%20Android&component=WebExtensions%3A%20Compatibility&component=WebExtensions%3A%20Developer%20tools&component=WebExtensions%3A%20Experiments&component=WebExtensions%3A%20Frontend&component=WebExtensions%3A%20General&component=WebExtensions%3A%20Request%20Handling&component=WebExtensions%3A%20Untriaged&product=Toolkit&list_id=13631066)

~~~
yborg
It baffles me that they would force-disable legacy extensions without having
supplied feature parity in the API. There are major extensions like Self-
Destructing Cookies that are one of the reasons that I still use FF that don't
have WebEx equivalents. Without these Firefox is Chrome with inferior
performance.

Is there a config switch for enabling legacy extensions in 57+?

~~~
throwanem
As far as I'm aware, 57 won't include the XUL API at all, whether behind a
config flag or otherwise. I'm not sure how updates from 56 will be handled -
one hopes users on the Release channel, who have add-ons the update will
break, won't just find themselves hosed by surprise. I haven't heard much of
anything about how that actual process will be managed, though.

(Self-Destructing Cookies looks like it could be reimplemented on the
WebExtensions API, but the dev doesn't seem to have any interest in doing so.
That's a shame, but it doesn't mean no one else will do it.)

I don't blame Mozilla for pulling the trigger this way, though. Opening the
roadmap for general community discussion and veto would result in endless
bikeshedding, and users unwilling to abandon XUL add-ons in November have the
option of sticking with 52 ESR or just not updating past 56 for a while.
Conversely, waiting for feature parity with XUL would mean probably another
three or so years before e10s hit stable, and Firefox is already three or more
years behind in that regard - that much more delay might well not be
survivable.

It's not a great situation to be in, but I can't see how Mozilla could've
found a better option than the one they chose, and I say that as one who will
lose some cherished add-ons in the transition - but if it's that or switch to
Chrome because Firefox is too slow to be usable, I'll take the former, and I
was strongly contemplating the latter before e10s became a thing. I doubt I
was the only one.

~~~
oridecon
AFAIK there's no way to destroy localStorage data so that's a problem for
extensions like SDC

~~~
throwanem
Content scripts can access the window object of the page in which they're
injected, so that shouldn't be an issue, I don't believe - if the page in
which a content script is running can remove data from localStorage, the
content script itself can, too.

~~~
mook
One of the reasons I use that extension is that it deletes things a short
while _after_ the last tab for a site is closed (so they undoing the close
lets me keep going). In that case there's no content in which to run scripts.

~~~
oridecon
[https://bugzilla.mozilla.org/show_bug.cgi?id=1340511](https://bugzilla.mozilla.org/show_bug.cgi?id=1340511)

------
JosephLark
Does this include the pausing of videos opened in a background tab until the
tab is first focused? I recall that it was held back from the expected FF 53
release and expected in 54, but I'm not seeing anything about it.

Edit: Just tested, and it seems like this is not included yet again. Will it
come out in FF 55, in... 6 weeks?

Edit 2: Not sure if this would reach anyone who can fix it, but heads up that
both links about the multiprocess firefox point to the Mozilla blog, not to
medium as stated in the second link. Is it supposed to be this page linked to
from the blog post? [0]

[0] [https://medium.com/mozilla-tech/the-search-for-the-
goldilock...](https://medium.com/mozilla-tech/the-search-for-the-goldilocks-
browser-and-why-firefox-may-be-just-right-for-you-1f520506aa35)

Edit 3: Plenty of people seem to be suggesting this is available already. I
think that has been the case for awhile now, but not by default. It was
something that was mistakenly specifically called out in the release notes for
53. I thought it was a much large discussion thread, but this is the comment I
was recalling [1] with a reply linking to the bug report [2] which claims it
was added to the FF54 release notes 3 months ago, but has seen action since
including discussion in another bug just two days ago.

[1]
[https://news.ycombinator.com/item?id=14151468](https://news.ycombinator.com/item?id=14151468)

[2]
[https://bugzilla.mozilla.org/show_bug.cgi?id=1308154](https://bugzilla.mozilla.org/show_bug.cgi?id=1308154)

~~~
throwanem
I don't know if it is surfaced in about:preferences, but I know the
functionality exists in Firefox 53 at least, since that's what I'm using now
(32-bit 53.0.3, Windows).

In about:config, look for media.block-autoplay-until-in-foreground.

~~~
maxxxxx
They really need to work on usability for the regular end user if they want to
succeed. So many useful settings are buried deep down in about:config. The
auto play settings should be super accessible.

~~~
asadotzler
The autoplay disabling isn't ready yet and that's why it's still behind an
about:config flag.

~~~
throwanem
Unready in what way, if you don't mind my asking? I haven't seen it misbehave
yet, although I grant that's n=1.

~~~
cpeterso
Some buggy video players are broken when the browser doesn't autoplay
"autoplay" video because the player's play/pause state doesn't match the
browser's. Firefox developers are looking at workarounds like telling the
player the video is playing, but not downloading the video.

You can set about:config pref "media.autoplay.enabled" = false to test.
YouTube used to be broken. I don't know if it still is.

~~~
throwanem
I think it still is - I had to re-enable autoplay to get YouTube playlists
working properly again.

I still have "don't autoplay until tab focused" enabled, though - it isn't a
problem there.

~~~
cpeterso
I'm not sure why "don't autoplay until tab focused" works but "don't autoplay
on current tab" does not. btw, I use the "YouTube High Definition" Firefox
extension, which allows you to prevent autoplay and tweak other YouTube
parameters such as disabling overlay messages and forcing a default video
size:

[https://addons.mozilla.org/en-US/firefox/addon/youtube-
high-...](https://addons.mozilla.org/en-US/firefox/addon/youtube-high-
definition/)

~~~
throwanem
I suspect it's because the transition between one playlist video and the next
triggers the autoplay-prevention code path. "Don't autoplay until focused"
wouldn't, because if the tab hasn't been focused then the video's not playing
at all, and if the tab _has_ been focused, then autoplay is (I think)
permitted without further restriction.

------
pkrumins
As always, I just added Firefox 54 to Browserling. You can try this new
version at this URL without installing or updating it:

[https://www.browserling.com/firefox/54/news.ycombinator.com](https://www.browserling.com/firefox/54/news.ycombinator.com)

I've a bunch of VMs available for free testing. If there are too many people
wanting to try it, then you'll have to wait in a queue for a few minutes.

~~~
vfaronov
[https://www.browserling.com/#pricing](https://www.browserling.com/#pricing)
says “Internet Explorer 9 only”, “Windows Vista only” — must be out of date?

~~~
pkrumins
That's what free users get. They better upgrade to developer plans and unlock
all IEs and all platforms.

~~~
ptman
Any plans now that Vista and IE9 are no longer supported?
[https://support.microsoft.com/en-us/help/22882/windows-
vista...](https://support.microsoft.com/en-us/help/22882/windows-vista-end-of-
support)

~~~
pkrumins
Yup, I'll be changing the default platform for free plans. I'm already working
on that. Free users will be able to use IE11. Like this:

[https://www.browserling.com/ie/11/news.ycombinator.com](https://www.browserling.com/ie/11/news.ycombinator.com)

------
Callmenorm
I recently switched back and Firefox has been much more responsive. It feels
great all the time now. I was using Brave for a while, but suddenly
performance took a hard dive.

------
silverwind
A nice tidbid for CSS developers:

    
    
        <input> elements of types checkbox and radio with -moz-appearance: none; set on them are now non-replaced elements, for compatibility with other browsers
    

This means that checkboxes and radio buttons can finally be styled like
regular HTML elements. Goodbye label hacks.

~~~
callahad
Edit: I believe my comment here was incorrect. Apparently we only rolled back
support for `appearance` and `-webkit-appearance` (and a few associated
changes), but `-moz-appearance` _does_ still work as described above. Original
comment follows:

I'm so sorry. This was rolled back during 54 Beta due to regressions on other
websites:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1368457](https://bugzilla.mozilla.org/show_bug.cgi?id=1368457)

Where did you see this mentioned, so I can go and correct those release notes?

~~~
extra88
It's in the Firefox 54 for developers [0], references bug #605985 [1]

[0] [https://developer.mozilla.org/en-
US/Firefox/Releases/54#CSS](https://developer.mozilla.org/en-
US/Firefox/Releases/54#CSS)

[1]
[https://bugzilla.mozilla.org/show_bug.cgi?id=605985](https://bugzilla.mozilla.org/show_bug.cgi?id=605985)

~~~
callahad
Huh, maybe only the unprefixed version was rolled back. This is why I don't do
frontend work. ...let me go ask my colleagues about this...

------
toyg
Looking at the Addon Manager, it's pretty grim. About half of the extensions I
need are not compatible with multiprocess. That includes stuff like img2tab,
it's all text, live http headers, rest client, tabtrekker, pinboard... I guess
the migration will take a while.

~~~
yaantc
You may want to check the detailed reports using the "Add-on Compatibility
Reporter" extension. I found that the default indication is very conservative,
and I used several extensions that were initially marked as not compatible,
but actually worked well.

So for the incompatible ones, particularly if they're rather niche (= not many
people tried them with electrolysis), you may want to force multi-process and
try them. And don't forget to make a report using the Reporter add-on, whether
it went well or not ;)

~~~
toyg
Thanks for the suggestions - I've now done them and it all looks ok with
multiprocess forced.

~~~
ionised
I have four addons that are apparently incompatible.

How do you _force_ multiprocess without disabling these addons?

~~~
toyg
Go to about:config and add the weirdly-named boolean
"browser.tabs.remote.force-enable", set to true. Restart FF.

Addons won't be disabled, but they might not work properly. If you see
misbehaving extensions, install the Add-on Compatibility Reporter extension,
then report by either:

* going to the Addons/Extensions screen and clicking "Report Issue" near the misbehaving extension

* clicking on the green puzzle piece now in your main toolbar, clicking on the X near the extension name, and then hitting the Submit button at the bottom.

The latter will also send a report saying the other extensions are actually
good, so I would do it only after making sure you've somewhat tested all of
them.

(All this was learnt today by insistent experimentation; the Addon Compat
Reporter could do with some extra documentation or hints on what to do.)

~~~
ionised
I'm not seeing that boolean for some reason. I'm seeing;

 _browser.tabs.remote.autostart_

 _browser.tabs.remote.desktopbehavior_

 _browser.tabs.remote.separateFileUriProcess_

but not the one you mentioned.

I'm on Firefox Developer Edition 54.0b14 (64-bit) if that makes any
difference.

~~~
toyg
It's not there by default, you must create it yourself. Right click on the
list of option and select new -> boolean.

------
snakeanus
How does Electrolysis perform when compared with firefox with a single process
when using many (500+) tabs? Do tabs that have not been loaded yet (such as
when using the click-to-load feature for tabs saved from previous seasons) use
their own process?

~~~
callahad
Here's a whole article on the new process model: [https://medium.com/mozilla-
tech/the-search-for-the-goldilock...](https://medium.com/mozilla-tech/the-
search-for-the-goldilocks-browser-and-why-firefox-may-be-just-right-for-
you-1f520506aa35)

The overhead is minimal since we're not doing process-per-tab: we cap the
number of processes to 4 by default. So if you have 500 tabs, loaded or
otherwise, you're not going to have 500 processes. I _believe_ we spin up the
processes on demand, so if you have 499 unloaded tabs and 1 loaded tab, you
should only have one content process, but I'd have to source dive to confirm
that.

~~~
deprave
Please DO process-per-tab. I have a lot of memory. I want you to use it. If
it's not enough, I will buy more memory or a stronger device. But please,
whatever you do, don't make security or stability trade offs for me. The M:N
threading model has never worked out. We know 1:1 works. Please do that.
Please, please, _please_ use a process-per-tab.

~~~
krzyk
Why? You can change the number of processes to e.g. 1000 and you will
basically get one process per tab until you reach 1000 tabs, and if you do,
you will need really a large amount of memory.

one process per tab is specifically why I quit using chrome, it wasn't working
even for small amount of tabs (100) it ate RAM like crazy. Mozillas approach
is better, user can control how many processes are created - users have
control.

~~~
deprave
It's simple. There is no way Firefox can guarantee anywhere near the level of
stability and security Chrome offers without a process per tab. OS primitives
operate in terms of processes (scheduling, memory, sandboxing, and so on) and
Firefox will not be able to use any of them. I really want to use Firefox, but
I'm almost certain not doing a process-per-tab will be the last nail in its
coffin. The code will be more complex to maintain, and no advantages in
security or performance will be gained, leading to less users and thus less
maintainers.

If there was one thing that caught my attention with Chrome back when it was
released (2008?) it was its reliance on OS primitives (processes) as the
building blocks for a stable and secure browser. This is essentially the same
argument the Varnish folks did when comparing to other proxy solutions like
Squid back in the day. I don't understand why Firefox is taking this route.

~~~
pcwalton
> There is no way Firefox can guarantee anywhere near the level of stability
> and security Chrome offers without a process per tab.

It has no security benefit without Site Isolation (which isn't unconditionally
a process per origin either for performance reasons). In both Chrome and
Firefox, any site can embed another cross-origin site in an iframe, and it
will share a process (and a main thread).

Chrome does not use an unconditional process per tab. Nobody would.

~~~
AgentME
I believe Chrome is moving to having cross-domain iframes in separate
processes. I remember seeing a flag for it.

~~~
pcwalton
Not for all sites unconditionally, only for those that opt into site isolation
or are high value. Too many sites have tons of iframes to do otherwise.

------
morsch
On a related note, offline pages on Firefox Android finally work again!

At least in the Beta release;
[https://bugzilla.mozilla.org/show_bug.cgi?id=1358946](https://bugzilla.mozilla.org/show_bug.cgi?id=1358946)

~~~
grigory
We also finally turned on "offline cache" support in Firefox For Android (for
50+ releases) - if you have a page in your cache, and you're attempting to
load that page while offline, it should "just work". See
[https://bugzilla.mozilla.org/show_bug.cgi?id=1232867](https://bugzilla.mozilla.org/show_bug.cgi?id=1232867)

------
JupiterMoon
The overhaul of responsive design mode is quite nice - and the dev tools seem
a little more performant.

------
tmaly
I am excited about the custom device option for responsive design mode. I use
the responsive design mode quite often.

the CSS clip path is another feature stoked about.

------
JohnTHaller
As always, Firefox Portable has been updated to 54.0:
[https://portableapps.com/news/2017-06-14--firefox-
portable-5...](https://portableapps.com/news/2017-06-14--firefox-
portable-54.0-released)

Firefox Portable is a portable package for Windows, so you can run Firefox
without altering any local browser installs or leaving personal details
behind. It's a fantastic way to run multiple versions side by side with
independent profiles for testing both websites and extensions. All versions of
Firefox are available including the latest Developer Edition, Beta version,
Extended Support Release, and Nightly releases. All packages are open source
under the GPL and totally free. And you can test alongside portable packages
of Opera, Iron, Maxthon, and SeaMonkey as well as the three main channels of
Google Chrome (Stable, Beta, Dev).

------
Lev1a
So when is it actually the stable release?

The updater inside FF says 53.0.3 is the most recent version and all the DL
links point to that version as well.

Edit (11 minutes after writing original comment): now it provides the update
through the "in-app" updater.

~~~
metalliqaz
They use staged roll-outs for new releases, so it could take several days to
show up

~~~
insertnickname
How is that responsible when v54 fixed several security problems?

[https://www.mozilla.org/en-
US/security/advisories/mfsa2017-1...](https://www.mozilla.org/en-
US/security/advisories/mfsa2017-15/)

~~~
lizzard
We have to weigh the potential risks against the potential benefits of a quick
rollout and try to come to a balanced decision. If we see a problem from
feedback from early installs, then we have a chance to quickly patch it and
re-release, sometimes within one day. Staged rollout is fairly standard in the
industry. (Speaking as a Firefox release manager)

~~~
cesarb
Indeed, a botched rollout can lead to users disabling automated updates (see:
Microsoft's GWX). Even if all you care about is security, you have to balance
the risk of not patching quickly enough with the risk of the user disabling
your ability to patch in the future.

------
m_st
Great work, but unfortunately I had to restart 3 times as the partial update
failed and the full update had to be applied. I'm sure this could be done
automatically without asking the user to restart 2 more times, right?

------
moosingin3space
I'm curious -- if this is basically a scheduler for tabs onto system processes
(which it seems to be), what's the impact on input latency? I've read in
multiple places that Chrome's input latency is worse than it could be because
of multiprocess, so I'm really interested to see some input latency
benchmarks.

Additionally, how are tabs sharing the same process isolated from one another?
Chrome uses Linux namespaces for each of its processes, and this keeps tabs
separated by a sandbox that requires a kernel exploit to break out of, how
does Firefox's sandboxing work within a process?

~~~
callahad
I'm not familiar enough with our in-process isolation to summarize it, but
[https://wiki.mozilla.org/Security/Sandbox](https://wiki.mozilla.org/Security/Sandbox)
is an good trailhead for the process-level sandboxing in Firefox.

------
inDigiNeous
Love it, after an day of use, feels snappier, more responsive definitely on my
"old" 2010 mpb. Also love the new compact theme, feels really slick with these
improvements.

Had to give up Chrome on this machine because it kept crashing my machine, and
go back to Firefox, but I'm happy of the improvements they are constantly
making.

Though managed to crash my browser by runnign a heavy javascript application
in one tab already. But that would lock up the previous one also.

------
soganess
Mozilla needs to stop chasing Google in this never ending quest to turn
Firefox, quite literally, into the winning combination that is Chrome.

Just because Chrome is a winning formulation, doesn't mean it is the only one.
My armchair example is themes... both chrome and ff now look like alien
invaders of corporate identity on my desktop. While that makes sense for
Google, it hurts Mozilla's image with the community of hackers/tinkers that
love Firefox for features just like that one; features that quietly say, "its
your browser, you likely know best". Especially because themes worked
reasonably well for so long(at least from the users perspective, I'm told the
implementation was fragile).

Maybe its time to go all in on the hacker community and make Firefox, a "Linux
first" browser. The PC market shrinking, no one is arguing that. Trying to
squabble over pieces of an ever shrinking pie is not a recipe for success.

This is especially true for Mozilla. All its competition can simply forget
about their browser products and still be profitable. A failed Firefox likely
means Mozilla disappearing for the digital landscape.

I propose that the Linux/Hacker community is the logical conclusion of PC
itself and, by proxy, the PC browser market. Long after everyone has gone
tablet or whatever, the last hold out of the PC market will be the Linux
diehards, why not cater to them from the get go? You are going to be catering
to them when all is said and done.

As a tangent, a great starting "performance feature", which is what all this
e10s stuff is getting at, would be vaapi support for hardware accelerated
video on linux. You can't really call your browser fast when it chokes the CPU
on any 4k video. The the only browser to currently support it on linux...
sigh... chromium.

~~~
remir
Let's go further; I believe Firefox should compete against ChromeOS. The web
is the ultimate platform, Mozilla should know that, but now it's more and more
Google's platform.

The reality is that Chromebooks and Chromeboxes are great computers for the
masses. They're safe, secure, always up to date, no virus. They're great for
the elderly, schools, public libraries, etc.

You can buy a 85$ Chromebit dongle you plug into an HDMI port in your TV and
you can browse the web on your big screen, watch Netflix, etc.

Where is Mozilla? Nowhere.

~~~
callahad
We tried, in part, with Firefox OS. We failed.

~~~
sliken
Seems like Firefox OS should have been like Mint. Build on someone else's hard
work (ubuntu or debian), tune it for an inexpensive platform (like the most
popular netbook/chromebook/cheap laptop) and then work on on what makes it
easy to use and useful. Things like a nice default desktop, integrate some
cloud storage, automatic backups, user friendly tutorials, etc.

Generally being incompatible with whatever platforms applications (iOS,
android, or debian/ubuntu) is a kiss of death. People need their apps and
developers need aren't going to cater to a new minority platform with
approximately zero users.

------
hollander
The lag seems gone! :-) This is very promising!

------
berryg
This page causes Firefox Nightly to spike in CPU and Energy Impact. I notice
it earlier with pages with animated gifs on it. So, I installed some extension
to not autoplay animated gifs. Something on this page causes the CPU to spike.

------
throwanem
Not a duplicate exactly, but there's already discussion of the subject
underway at
[https://news.ycombinator.com/item?id=14547675](https://news.ycombinator.com/item?id=14547675)
.

~~~
kibwen
Looks like those comments have been folded into this thread.

------
romanovcode
> Today's release is the first to run Firefox using multiple operating system
> processes for web page content, making Firefox faster and more stable than
> ever.

So it's finally not slow and laggy? I hope someday it can be as snappy as
Chrome so I can ditch google forever.

~~~
throwanem
The functionality has been available on an opt-in basis for a while now, and I
can confirm that it massively improves Firefox's performance and
responsiveness. Whether it's "as snappy as Chrome" is a separate question;
I've never found that browser as responsive as seems to be the general
experience, so I can't really speak to the comparison, but I certainly can say
that Firefox itself is much more comfortable to use with e10s enabled.

~~~
danudey
I've found Chrome as buggy and unreliable as it's been fast and responsive. I
actually switched to Firefox on my Windows PC because Chrome just stopped
rendering properly (not just rendering HTML, the entire window was broken). I
also have to turn off users' hardware acceleration at the office so that their
'my tabs go blank!' bugs stop happening.

~~~
throwanem
I get a lot of weird graphical glitches with Chrome on Windows 7, too -
something about the way it draws its windows doesn't always play well with
DWM, so they'll leave bits of themselves behind when dragged, or flicker
weirdly when dragged across display boundaries, or otherwise uniquely
misbehave. Even on machines where the display hardware sucks enough to make
graphical oddities relatively common, Chrome stands out in the frequency with
which they occur.

~~~
darinf
You might confirm that your video driver is up-to-date.

