Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170329071901 [Note]: The preference "dom.ipc.processCount" is now set to 4 by default, so if I open Nightly having 4 opened tabs, I would expect to see 4 content processes allocated to the 4 opened tabs. [Steps to reproduce]: 1. Launch Firefox with a new profile 2. Use the task manager or Process Explorer app to monitor the opened content processes 3. In the already opened tabs, load 2 websites of your choice (hover the mouse over the tabs to check the content processes IDs) 4. Open a new tab and load any website 5. Open another new tab and load any website 6. Monitor the task manager/process explorer app [Expected result]: - In step 2 - 4 content processes should be seen in the task manager/process explorer: 2 main processes (resulted from opening Firefox on Windows) and 2 belongs to the opened tabs - In step 3 - the 2 content processes allocated to the loaded websites should remain the same - In step 4 - a new content process should be opened - In step 5 - a new content process should be opened [Actual result]: - In step 2 - 4 content processes are opened - In step 3 - the processes remain the same - In step 4 - 2 content processes are opened - only one of them is being used by the new opened tab. The other process will close itself after a while. - In step 5 - no other content process is being opened Please see the screencast for more details.

Thanks for the bug report. I try to give a few hints, I know this is confusing with all the different process types we have. We should have better tooling to make testing like this easier. (In reply to Simona B [:simonab ] from comment #0) > Created attachment 8852840 [details] > unusedCP.mp4 > > Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 > Build ID: 20170329071901 > > [Note]: The preference "dom.ipc.processCount" is now set to 4 by default, so > if I open Nightly having 4 opened tabs, I would expect to see 4 content > processes allocated to the 4 opened tabs. > I think it's a bit more complicated than that. We have several process types some of which are "web" content processes, the ones you're focusing on here. The Process Explorer shows all the other processes as well (main process, rendering process, GMP, process, web extension process, service worker process, file URI process, etc.). > > [Expected result]: > - In step 2 - 4 content processes should be seen in the task manager/process > explorer: 2 main processes (resulted from opening Firefox on Windows) and 2 > belongs to the opened tabs There is only one main process the other one might be something else, I think we might even use a thumbnail process for the starter page but I'm not sure... Again, probably we should have a better tool to visualize all the processes we have open and what are they used for. So an enhancement for what we have in about:performance. > - In step 4 - 2 content processes are opened - only one of them is being > used by the new opened tab. The other process will close itself after a > while. Could you try your experiment with something simpler, like google.com in all tabs? Preferably with a simpler starting setup, like with one tab with about:blank or google.com. These example sites are using way too many things to tell what is going on. Sites with no videos / plugin dependent content are a better indicator for what you're trying to test here. > - In step 5 - no other content process is being opened > Please see the screencast for more details. One other thing for the screen cast that it takes some time for the Process Manager to pick up new processes... also if you hover over a tab for a bit it shows the process ID for it's tab.

Mike, the process monitor we have in about:preferences I think would be a great place to monitor all the processes what we have, indicating their types as well (plugin, addon, web, service worker, etc). What do you think?

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #2) > Mike, the process monitor we have in about:preferences I think would be a > great place to monitor all the processes what we have, indicating their > types as well (plugin, addon, web, service worker, etc). What do you think? s/about:preferences/about:performance sorry for the typo I was in a rush...

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #1) > > - In step 4 - 2 content processes are opened - only one of them is being > > used by the new opened tab. The other process will close itself after a > > while. > > Could you try your experiment with something simpler, like google.com in all > tabs? Preferably with a simpler starting setup, like with one tab with > about:blank or google.com. These example sites are using way too many things > to tell what is going on. Sites with no videos / plugin dependent content > are a better indicator for what you're trying to test here. This issue is easily reproducible using google.com, even though it's a bit intermittent. > > - In step 5 - no other content process is being opened > > Please see the screencast for more details. > > One other thing for the screen cast that it takes some time for the Process > Manager to pick up new processes... also if you hover over a tab for a bit > it shows the process ID for it's tab. That's how I established that the 4th tab did not open in a new process.

(In reply to Simona B [:simonab ] from comment #4) > This issue is easily reproducible using google.com, even though it's a bit > intermittent. Thank you for testing it. I will try to investigate this in the next few days. Nominating it for triage, I think we should at least figure out what is exactly going on and block aurora uplift on it for now. This sounds a bit scary. If for some reason (docshell swapping or whatever) we spawn a temporary process and then use another one in the end for the new tab that would explain the various intermittents here (and in the last case because of the temporary process hits the maximum we pick another one for the one that we will actually use for the new tab from the existing ones and close the temporary). Not to mention the terrible performance cost of the extra work.

I've noticed that in a clean profile, running with ./mach run, it seems to spawn a new content process on startup, which goes away after a few seconds. Maybe that's the same thing.

I wonder if this is the Background Thumbnail capturing stuff. It looks like if a thumbnail isn't captured for a while, that thing destroys itself[1]. simonab, can you please try setting browser.pagethumbnails.capturing_disabled to true, restarting the browser, and then attempting to reproduce? [1]: http://searchfox.org/mozilla-central/rev/624d25b2980cf5f83452b040e6d664460f9b7ec5/toolkit/components/thumbnails/BackgroundPageThumbs.jsm#321-326

(In reply to Mike Conley (:mconley) - Digging out of review and needinfo queue from comment #7) > I wonder if this is the Background Thumbnail capturing stuff. > > It looks like if a thumbnail isn't captured for a while, that thing destroys > itself[1]. > > simonab, can you please try setting > browser.pagethumbnails.capturing_disabled to true, restarting the browser, > and then attempting to reproduce? > > [1]: > http://searchfox.org/mozilla-central/rev/ > 624d25b2980cf5f83452b040e6d664460f9b7ec5/toolkit/components/thumbnails/ > BackgroundPageThumbs.jsm#321-326 I added the preference browser.pagethumbnails.capturing_disabled and set it to true - and I'm still able to reproduce the issue.

I'm afraid I'm not sure then. To ensure we're not seeing GPU processes being created and destroyed, simonab, could you monitor the processes in about:performance? The table at the top will only list the parent and content processes, and filter our things like the compositor process. Do you still see the same behaviour there?

Yes, I see the same behavior. An additional content process is opened and closed after a while. Please see the screencast (Process ID 24684 is the additional process)

I see a content process starting up and then being shut down shortly after start up (like in comment 6). Let's start from there. It's a "web" content process and we create it for an about:blank when the only tab is the initial page that should not be rendered in a content process. I think what might happen is that the browser initially has remote=true attribute set and then for about:blank we create the content process but then when the page navigates to the starting page it switches remoteness and kills the child process (unless something else picks it up real quickly) The same might happen for about:newtab that we load in the bg, and that would explain the intermittent nature of this whole thing. (I also wonder if there is a race here, the creation is triggered from a script blocker removal that does end up in ShowRemoteFrame, maybe if we get here a bit later in the process of loading the chrome page we won't start up a content process for the initial about:blank) I hope I will have some more time to investigate this today but I'm not sure... Mike, I'm a bit lost in the front end code again... could this scenario be a reality or I'm on the wrong track?

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #11) > I hope I will have some more time to investigate this today but I'm not > sure... Mike, I'm a bit lost in the front end code again... could this > scenario be a reality or I'm on the wrong track? Some of it sounds plausible. The newtab case, for example, makes perfect sense: we open a new tab defaulting to remote="true", and browse it to about:newtab which causes us to flip remoteness (and if it was the only tab in that process) we kill the process. I'll note that the initial browser is, however, _not_ remote by default (bug 1357242 will try to address this). We do this kind of silly thing where we wait for DOMContentLoaded and flip remoteness on that initial browser to be remote. If the initial page we're going to ends up being non-remote, well, then we do yet another flip, and if that initial tab was the only one loaded in that process, there's another short lived process.

(In reply to Mike Conley (:mconley) from comment #12) > (In reply to Gabor Krizsanits [:krizsa :gabor] from comment #11) > I'll note that the initial browser is, however, _not_ remote by default (bug > 1357242 will try to address this). We do this kind of silly thing where we > wait for DOMContentLoaded and flip remoteness on that initial browser to be > remote. If the initial page we're going to ends up being non-remote, well, > then we do yet another flip, and if that initial tab was the only one loaded > in that process, there's another short lived process. My part 4 patch in bug 1351358 comment 9, might address this case at least.

triage priority setting

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information