Closed Bug 535323 Opened 15 years ago Closed 14 years ago

[OOPP] Closing the only tab that is using a plug-in should kill the related mozilla-runtime.exe process

Categories

(Core Graveyard :: Plug-ins, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 501485

People

(Reporter: u88484, Unassigned)

References

()

Details

Closing the only tab that is using a plug-in should kill the related mozilla-runtime.exe process.

STR:
0) Open the windows task manager to the processes tab
1) launch firefox with google.com
2) go to youtube.com (notice the mozilla-runtime.exe process)
3) close the youtube.com tab (no need to watch a video)

The mozilla-runtime.exe process stays open and only freed up 100 K of memory.  The memory held would probably be a lot greater than around 6,000 K if I had actually watched a video but I didn't test that.  The way things are could potentially hog a huge amount of memory if a user opens a bunch of tabs with a lot of different plug-ins.  Imagine the backlash for the memory consumption tin foil hat club.
Summary: Closing the only tab that is using a plug-in should kill the related mozilla-runtime.exe process → [OOPP] Closing the only tab that is using a plug-in should kill the related mozilla-runtime.exe process
Results after watching a video:

Just opening youtube.com was around 6,000 K
Closing youtube.com without watching a video resulted in releasing 100 K
Watching the video memory went to 39,000 K
closing the youtube tab and memory went down to 13,000 K
This is very much related to bug 500925, and isn't specific to OOPP.
Adding 'plugins.unloadASAP;true' does kill the process as soon a tab using that plug-in is closed.

I couldn't find in the bug you linked to the actual time limit until the process is killed.  There was talk of 10 minutes but that doesn't seem like it was the final answer.

So users that complain of memory being held by for plugins that might be used again in same session should add 'plugins.unloadASAP'?  I just foresee a lot of complaints from users complaining about the memory being held.
I don't see anything beyond 501485 here, except that whatever unloading heuristic that's used could/should account for the extra time needed to launch a plugin subprocess on top of initializing the plugin dso.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.