Meet the browser: Firefox Next

By bogas04
in Web Browser Discussion & Support

 Share

Recommended Posts

  • 3 weeks later...
  • 3 weeks later...
  • 5 weeks later...
Veteran

BooBerry

Posted
Posted
Quote

Servo Q2 2016 Deliverables

Focus is on the June tech demo of Servo+Browser.html

- Make Browser.html work fluidly

- Get end-to-end performance and layout solid for our target set of websites

June is also when the first Rust code ships in release Firefox!

 

larsberg
Improve Windows and Android
Oxidation/Rust-in-Gecko coordination
 
pcwalton
browser.html P1s for June

Ensure that the browser.html is in good state for the June tech demo

 nox

SMUP to pick up promises

make devtools work

 shinglyu
Initial tracking of Servo performance

 Manishearth
jdm
Implement content blocker
Support bHTML projects like referrer policy, persistence, and HTML parser speculation

froydnj
Land support for multiple Rust components in Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=1163224 )

Kyle Headley is joining us from U. Colorado at Boulder, where he is working with Matthew Hammer on incremental computation. He’s going to be working as a Research Assistant this summer, helping us find ways we can use incremental computation to improve the performance of Servo. He’s kheadley on IRC.

Manish Goregaokar is a long-time Servo contributor, initially participating in the first round of Google Summer of Code with Servo. He has mostly worked on DOM-related issues and Rust itself, but is looking forward to working on new things. He is currently working remotely from Mumbai, but will be relocating to the San Francisco office later this year. He is manishearth on IRC.

Diane Hosfelt previously did network and protocol analysis for the Department of Defense, and will start out working on Servo’s networking (an area sorely in need of some expert work!). Diane is working remotely from the UK. She is dd0x68 on IRC.

Welcome to the team, everybody!
Planning and Status

Our overall roadmap and quarterly goals are available online.

This week’s status updates are here.
Notable Additions

    Manish added support for submit button data in form submissions
    Jack made Servo DPI-aware on Windows
    nox hoisted out a channel creation to reduce the number of channels and threads Servo creates
    larsberg enabled AppVeyor/Windows testing on ipc-channel
    dati implemented Included Services support for WebBluetooth
    ajeffrey reduced the number of threads used in our scheduler
    rzambre changed the profiler file output from CSV to TSV format
    emilio added support for constants in classes in geckolib
    ms2ger implemented reporting of panics in web worker threads
    bholley added basic support for Gecko atoms
    mbrubeck optimized text shaping for ASCII text
    KiChjang implemented support for -moz-user-* CSS longhands in geckolib
    jdm created markers for network and JS-related events in the timeline profiler
    izgzhen filled in many missing pieces related to file inputs in forms
    fduraffourg ported a large set of HTML/JS tests for cookie handling to Rust unit tests
    wafflespeanut improved the usability of the highfive automated tests
    creativcoder enabled intercepting network requests and synthesizing responses

 

  • 2 weeks later...
Grand Master

oldtimefighter

Posted
Posted (edited)

Firefox 48 Beta, Release, and E10S

 

I am beginning to think E10S aka multiprocess is never going to come to the release channel of Firefox. I have been on the beta channel for a while now hoping it would be on by default soon but nope. Not that it matters, I tried forcing it on but my LastPass extension causes havoc with the browser. I am now deciding between just going back to the release version of Firefox or ditching LastPass.

  • 2 weeks later...
Veteran

max22

Posted
Posted
On 6/7/2016 at 0:58 PM, Boo Berry said:

LastPass works fine with e10s here.

 

Looks like they're going to roll e10s out slowly starting with Firefox 48.

What version of lastpass are you using that works fine with e10s please?

 

 

So far tried Firefox nightly and e10s are really nice with 12 tabs having 12 nightly processes! Really speeds things up!

Veteran

BooBerry

Posted
Posted
Quote

most of the main addons I need, work well in FF 50 with e10s enabled.
But I am still not sold to the performance gains, Nightly still freezes or lags when I open multiple tabs or I have already opened many heavy pages like YouTube.
If Mozilla wants their user base to jump to the new architect, the price of losing the functionality of their incompatible addons must be justified at least.

 

if you load more than 10 tabs at once then e10s will be indeed much slower than non-e10s if you have adblocker installed. And by "much slower" I mean from 60% to 1800% slower. Take a look at this post and Palant's response:
https://bugzilla.mozilla.org/show_bug.c ... 192585#c17

It's not exactly surprising that Adblock Plus slows things down slightly with e10s (the significant slowdown you see there only occurs if you load lots of tabs in parallel which people usually don't). Content policies require synchronous actions, meaning that Adblock Plus has to do synchronous messaging from the content policy implementation and block the content process. As long as there is no way to respond asynchronously from content policies this isn't going to change.


Also, there is a bug filed already that is supposed to remove this bottleneck:
https://bugzilla.mozilla.org/show_bug.cgi?id=1280368

 

Over time the needs changed and we should consider implementing an asynchronous API for content blocking which could replace nsIContentPolicy. Let's gather some thoughts and ideas within this bug as a first measure.

 

For reference, this is currently causing performance issues in Adblock Plus with e10s. Our content process code needs to query the parent for content policy decisions because that's where the state is. Currently it has to happen synchronously because nsIContentPolicy requires a synchronous decision - so rather than delaying a single network request slightly we block the entire content process every time. IMHO, that's what is causing the issue described in bug 1192585

 

Veteran

BooBerry

Posted
Posted
Quote

https://bugzilla.mozilla.org/show_bug.c ... 192585#c21

@ajfhajf, did you test uBlock or uBlock Origin ("uBO")?

uBlock Origin blocks minimally the content process: filtering -- the most CPU intensive task for the extension -- is done by uBO's HTTP observer handler, not its nsIContentPolicy observer, so I am puzzled by your results. The only thing done by uBO in its nsIContentPolicy observer is to merely send a few pieces of data (4-5 fields) to the main process, which stores that information in a pre-allocated buffer. Later the HTTP observer in the main process retrieve that information to evaluate against uBO's filtering engine. Essentially the content process is virtually a noop, it's blocked just the time for the few fields of data to be stored in the main process.


However, according to my measurements in this post https://bugzilla.mozilla.org/show_bug.c ... 192585#c19 , uBlock does slow the browser too.

 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing