User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20170914100122 Steps to reproduce: 1. opened background tabs which are active in background (youtube, windy) 2. open gmail 3. start typeing Actual results: firefox sometimes lags on text input, which seems to be caused by other tabs interfering with the foreground tab. Just while typing this text, gmail in an another tab received a new mail - which caused a short lag even for this basic text field. Expected results: smoth text input - just like chrome

youtube-video of the behaviour described. Although video quality is poor, the lags are clearly visible.

free-form description: Recently I've noticed that one area where firefox feels slow for me is that it sometimes shows signs of "micro-stuttering" while typing. So with a few tabs open and listening to a youtube musik "video" in a background tab, it can happen that firefox is 2-3 chars behind while typing from time to time, which is quite irritating. On purpose (with a clean profile) I was only able to reproduce the issue in case the other tabs were activly loading content, however in my production setting (2 content processes due to memory limitations) I even get this behaviour with normal "background" tabs: https://youtu.be/DK5I7wkAmUw

If you could follow the steps in this page, a profile would help us identify the problem: https://developer.mozilla.org/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Could you try to follow the steps to produce a profile from your session? With a profile, we can pinpoint what is happening in the Firefox code and possibly patch the issue.

Hi Selena, I am not sure a profile would be that conclusive - however I've found a very simply way to reproduce the issue. 1. load pastebin.com in tab 1: https://pastebin.com/ 2. load the emscripten massive benchmark in tab 2: https://kripken.github.io/Massive/ 3. start the benchmark by clicking on the "run benchmark" button 4. switch to the pastebin tab and keep a key pressed On my machine, the massive benchmark induces many multi-second lags in the pastebin-tab. Agreed massive is not a typical background tab's workload, and with normal webpages loaded the lags are more like 500ms than 5s on my machine, but they are there and rather annoying when they occur while typing. I thought e10s was all about solving issues like this, but it seems there are still bottlenecks.

screencast illustrating the issue: https://youtu.be/Zt99Jcx-5ks

running the same test using chrome - there is a single short lag (<500ms): https://youtu.be/yWt7WQiPzko It might sound like a minor thing, but issues like this really hurt perceived performance - they contribute to the perception that firefox is a slow browser.

Andrew - Is this something BHR folks could have a look at?

I'm surprised background tab budget-based throttling isn't help here. Andreas, do you have any ideas? Nika, this kind of thing would just show up in the aggregate on aws(m)y, right?

Budget throttling should help, but only for timeouts and only 30 seconds after the load event. If there are many runnables, then they could indeed interfere. The Q-DOM scheduler is where we hope to improve this.

what makes me wonder - I have two content processes, why/how can one block another for ~5s? I thought this is one of the major selling points of multi-process-firefox?

(In reply to Clemens Eisserer from comment #13) > what makes me wonder - I have two content processes, why/how can one block > another for ~5s? > I thought this is one of the major selling points of multi-process-firefox? ... and of course, if the tabs are in different content processes then budget throttling doesn't matter at all.

Budget throttling only helps if there are many timers/etc adding up to jank. A single contiguous block of js or other work can still jank the foreground and there is nothing throttling can do. We need the Quantum DOM interrupting behavior to address this. Or more content processes.

is tab <-> process assignment fixed, or is the currently active tab simply using a currently idle content process?

We currently allocate up to 4 processes and assign tab groups to them psuedo-randomly. A tab group is a tab and any tabs its opened, etc.

Note, in FF57 there is a section for "performance" in settings. If you can uncheck "use recommended performance settings" and select up to 7 content processes.

Too bad a tab is assigned to a fixed content process, a group of heavy tabs will still slow each other down. With dom.ipc.processCount=2 and 2 tabs (pastebin and massive) I got multi-second lags, while with dom.ipc.processCount=4 and two tabs everything works as expected. I set dom.ipc.processCount=2 a few months ago, as my machine is a bit RAM limited (6GB) when other heavy apps are running (Eclipse, LibreOffice, VirtualBox).

(In reply to Andrew Overholt [:overholt] from comment #11) > I'm surprised background tab budget-based throttling isn't help here. > Andreas, do you have any ideas? Nika, this kind of thing would just show up > in the aggregate on aws(m)y, right? Yeah, this would show up there if the slowness in typing was long enough to exceed 128ms. If it's less than that we won't consider it a hang & therefore will ignore it. You can probably find hangs like this with the "user interacting" flag, but it won't be super useful, as you'll just see that content JS is running.

(In reply to Clemens Eisserer from comment #19) > Too bad a tab is assigned to a fixed content process, a group of heavy tabs > will still slow each other down. > > With dom.ipc.processCount=2 and 2 tabs (pastebin and massive) I got > multi-second lags, while with dom.ipc.processCount=4 and two tabs everything > works as expected. I set dom.ipc.processCount=2 a few months ago, as my > machine is a bit RAM limited (6GB) when other heavy apps are running > (Eclipse, LibreOffice, VirtualBox). Thanks for the update. Given that the default settings improved performance for you, I'm going to resolve this as WORKSFORME. Per earlier comments about work we'll be prioritizing in 2018, further enhancements in the DOM Scheduler may additionally improve performance in the use case you've described. Thanks for filling a bug and sharing the details of the issue with us!

The original test-case (2 tabs, 1 tab with pastebin, 1 tab with massive benchmark) works fine with 4 content processes, however the underlaying issue is still present: There is a fixed mapping tabs -> content-processes, and in case two tabs are in the same content process the active tab can be stalled by a background tab assigned to the same content process for SEVERAL SECONDS. So I would kindly ask, to re-open the bug and only close it when either: * the scheduler is improved, so that two tabs on the same content process can't stall each other * (preferred) the fix assignment tab <--> content process is re-worked, so that tabs can be migrated to other content processes.

In case re-opening the report requires another test-case scenario which reproduces the issue with default settings, I would construct/find one.

Ultimately this is a big known issue that we are continuing to work on. That work is going to be happening in other bugs, though. I guess we can leave this open depending on that other bug as a sign post for other people who notice the same issue. Does that sound reasonable Selena?

Sure. As long as this lives in DOM. :)