The stray processes only consume 3.2 MB of RAM and no processor cycles. They are annoying only because if I delete one of those local html files, I cannot also delete the containing folder until I first open Task Manager to track down and close the stray process. I find it interesting that I can delete the html file but not the folder. Also: If I close a Firefox window that has some of those local html files open and also use Task Manager to close all of the stray processes, when I reopen Firefox it restores all of my tabs WITHOUT spawning any of those stray processes.
Hello Rob, Is this problem still occurring in Firefox 42.0 or Nightly 46.0a1? I can not reproduce this bug on 42.0 or 46.0a1. Name Firefox Version 46.0a1 Build ID 20151217030207 User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0 Thank you, Justin
It was still happening with FireFox 42. I just upgraded to 43.0.1 and the restart failed because of the extra processes waiting to be killed in taskmanager. Sometimes I ended up with dozens of extra processes because I might go weeks between restarts of FF and read a lot of HTML ebooks in the interim. So far no extra processes with 43.0.1 but I only installed that update a few minutes ago.
I understand Rob. I will check back with you in a couple weeks and see if we should close this bug. For now I will leave it open.
Hello Rob, Just checking back with you to see if this bug is still relevant on the newer releases.
I had this issue again two ago with 43.0.4 when Firefox needed to restart for an upgrade to an extension. It refused to restart because of the extra process. I killed the extra process and then FF restarted normally. When I think to check for that extra process right after opening a local HTML file, if an extra process was created I can kill it without having any apparent effect on the operation of the remaining FireFox process. When I first created this bug I could count on an extra process being created EVERY time I opened a local HTML file - sometimes I would have a dozen extra processes if I had read a lot of ebooks between restarts. Since FireFox 42.x.x the extra processes are hard to produce but they still occur once in a long while. When I do notice that opening a local HTML file has caused an extra process ... it is no longer reliably reproducible. The 3-step process of closing that particular HTML file in FF, restarting FF, then reloading that HTML file might have to be repeated dozens of times before the extra process pops up again. Since I'm the only one who seems to be seeing this issue and I know how to cope with it when it happens, I wouldn't have any objection to closing the bug - I'm sure most coders working on FireFox have more important things to work on.
Ok. This sounds like an e10s issue. Which is being updated a lot so I will pass this up to a dev.
Status: UNCONFIRMED → NEW
Component: Untriaged → Tracking
Ever confirmed: true
Product: Firefox → Core
QA Contact: chofmann
This almost certainly has nothing to do with e10s, because e10s has not been enabled on release, certainly not going back to 40-43! I'm very surprised that this is a firefox.exe process. If it were a plugin-container.exe process, it's possible that this is the thumbnailer, or something else. I'm happy to just close this out, because it seems specific. But Rob if you want to debug, here's some things you can try: * Install and use https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx to figure out the exact command line that was used to launch the phantom firefox.exe process. * If the phantom process is using little or no CPU, you can try to submit a hang report for it and that will help me know what the process is doing: https://developer.mozilla.org/en-US/docs/Mozilla/How_to_report_a_hung_Firefox has instructions. Note that crashfirefox.exe by default will kill a random firefox.exe process. Since you have more than one, you need to find out the PID of the "phantom" one (using process explorer) and then run `crashfirefox.exe thatpidnumber` to kill that one and not your "main" Firefox. I'm on vacation for the next few weeks; I'll see if I can get another engineer to pay attention to this bug while I'm gone.
Component: Tracking → Untriaged
QA Contact: chofmann
Hello Rob, did the above statement help with this issue or is it still persistent?
I haven't tried the process explorer since I tried and failed to download it after it was first suggested ... then forgot all about it. I just downloaded it now and I'll take it out for a ride around the block. Might be a while before I have anything to report - it has been at least 2 weeks since I've had any of those extra FF processes showing up in Task Manager. Just FYI, McAfee antivirus was deleting ProcessExplorer every time I downloaded it - or, if I downloaded it on another machine and copied it onto mine it would kill it if I tried to run it. I have since switched back to Norton and it let me download and run it.
I just spent 90 minutes opening one HTML e-book after another - trying and failing to provoke one of those extra processes. At 2 or 3 per minute to open the e-book, check Task Manager for an extra process, close the file, I would guess I made 200+ attempts. Currently running FF 47.0.1
Closing as WFM Per comment 11.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598
Component: Untriaged → General
You need to log in before you can comment on or make changes to this bug.