Re: [tor-bugs] #21876 [Applications/Tor Browser]: e10s is not enabled on Linux (and probably OS X) by default in ESR 52 based nightlies

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#21876: e10s is not enabled on Linux (and probably OS X) by default in ESR 52 based
nightlies
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:  new
 Priority:  Very High                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Major                                |     Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,        |  Actual Points:
  TorBrowserTeam201704                           |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by cypherpunks):

 The more testing is performed, the more obvious it becomes that the main
 reason
 > e10s is not enabled on Linux (and probably OS X) in ESR 52 based
 nightlies
 is "e10s is the holy crap!".
 Now it takes >400MB to open the first website (doubled). Performance
 degraded enormously as two processes concurrent for the same resources (no
 offloading of the parent). Add-ons become inadequate, GUI too. Even
 Mozilla realized that and asked developers to focus their efforts on
 WebExtensions (required for Nightly this summer) by updating
 https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57
 -compatibility-milestones/
 In its current implementation e10s is a way to make 2 firefox.exe instead
 of one. Child process continues to use loopback connections, ask system
 DNS service and printer spooler service, have access to memory (as
 sandboxing will be later) and, as some idiots at Mozilla made it a memory
 I/O hog, try to allocate new memory objects when lacking of resources, so
 successfully grow to OOM by the child process and then crash with the
 parent (rofl:)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21876#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs