Achwaq Khalid Reporter
	Description • 10 years ago

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141024080301

Steps to reproduce:

Assuming E10S is enabled

1 - Open this PDF link http://arxiv.org/pdf/1410.6192v1
2 - Navigate through the document and then close it


Actual results:

While a 103 pages pdf file can really cause a significant memory usage closing it won't solve the issue


Expected results:

Firefox must open every newly opened PDF file in a new plugin-container so that the memory associated with it will be fully recovered whenever that child-process/tab is closed

	Nicholas Nethercote [inactive]
	Comment 1 • 10 years ago

I just tried this document on Linux. Memory usage was very reasonable -- RSS didn't exceed 300 MiB scrolling through the PDF -- and the tab's memory was reclaimed as expected when I closed the tab.

Achwaq, when you see the high memory usage, could you please open a new tab, type "about:memory" in the address bar, click on the "Measure..." button, and then upload the resulting file to this bug? That will give us better information. Please note that if you do this all the tabs you have open will be visible; if that's a problem you can click on the "anonymize" check box before hitting "Measure...". Thank you.

	Brad Lassey [:blassey] (use needinfo?)
	Comment 2 • 10 years ago

Achwaq, does that summary capture the problem? If so, do you have any addons installed? Also, have you changed the number of processes? More than one content process isn't well supported yet.

	Achwaq Khalid Reporter
	Comment 4 • 10 years ago

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #2)
> Achwaq, does that summary capture the problem? If so, do you have any addons
> installed? Also, have you changed the number of processes? More than one
> content process isn't well supported yet.

The problem is not that PDF.js uses a huge amount of memory but from an architectural point of view and for the sake of performance and stability it will be better that firefox fires a new container for every newly opened PDF document, I already discussed this with Mike in twitter (https://twitter.com/mike_conley/status/515199655747923968) and I just want to file a bug for it to keep things in track, this being said I don't think that the summary name save the initial purpose now!

	Achwaq Khalid Reporter
	Comment 5 • 10 years ago

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #2)
> Achwaq, does that summary capture the problem? If so, do you have any addons
> installed? Also, have you changed the number of processes? More than one
> content process isn't well supported yet.

Oh yeah and as of the number of processes i'm still sticking with ProcessCount=1 otherwise a sample pop-up will crash my tabs :)

Application Basics
------------------

Name: Firefox
Version: 36.0a1
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Multiprocess Windows: 1/1

Crash Reports for the Last 3 Days
---------------------------------

Report ID: bp-de0b77a8-a652-4134-9a31-cae612141027
Submitted: 24 hours ago

Report ID: bp-e6a5d18e-73b9-4122-860a-760922141027
Submitted: 1 day ago

All Crash Reports (including 4 pending crashes in the given time range)

Extensions
----------

Name: Adblock Plus
Version: 2.6.5
Enabled: true
ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}

Name: Flagfox
Version: 5.0.8
Enabled: true
ID: {1018e4d6-728f-4b20-ad56-37578a4de76b}

Name: OneTab
Version: 1.9
Enabled: true
ID: extension@one-tab.com

Name: Open With
Version: 5.6.3
Enabled: true
ID: openwith@darktrojan.net

Name: Quick Translator
Version: 2.0a1
Enabled: true
ID: {5C655500-E712-41e7-9349-CE462F844B19}

Name: Restart
Version: 1.2.3
Enabled: true
ID: Restart@schuzak.jp

Name: SearchPreview
Version: 7.1
Enabled: true
ID: {EF522540-89F5-46b9-B6FE-1829E2B572C6}

Name: Session Manager
Version: 0.8.1.6
Enabled: true
ID: {1280606b-2510-4fe0-97ef-9b5a22eafe30}

Name: Tab Counter
Version: 1.9.9
Enabled: true
ID: tabcounter@morac

Name: Tab Scope
Version: 1.5
Enabled: true
ID: tabscope@xuldev.org

Name: Turn Off the Lights
Version: 3.0.0.16
Enabled: true
ID: stefanvandamme@stefanvd.net

Name: FastestFox
Version: 5.2.1
Enabled: false
ID: smarterwiki@wikiatic.com

Name: IDM CC
Version: 7.3.87
Enabled: false
ID: mozilla_cc@internetdownloadmanager.com

Name: Multi Links
Version: 3.0.0.19
Enabled: false
ID: multilinks@plugin

Name: User Agent Overrider
Version: 0.2.4
Enabled: false
ID: useragentoverrider@qixinglu.com

Name: WiseStamp
Version: 3.13.44
Enabled: false
ID: wisestamp@wisestamp.com

Graphics
--------

Adapter Description: NVIDIA GeForce 9700M GT
Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM: 512
Device ID: 0x064a
Direct2D Enabled: true
DirectWrite Enabled: true (6.3.9600.17111)
Driver Date: 7-2-2014
Driver Version: 9.18.13.4052
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 01451025
Vendor ID: 0x10de
WebGL Renderer: Google Inc. -- ANGLE (NVIDIA GeForce 9700M GT Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Important Modified Preferences
------------------------------

accessibility.browsewithcaret_shortcut.enabled: false
accessibility.typeaheadfind.flashBar: 0
browser.cache.disk.capacity: 358400
browser.cache.disk.smart_size_cached_value: 71680
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.cache.frecency_experiment: 1
browser.places.smartBookmarksVersion: 7
browser.sessionstore.max_tabs_undo: 20
browser.sessionstore.max_windows_undo: 10
browser.sessionstore.upgradeBackup.latestBuildID: 20141028030204
browser.startup.homepage: www.google.com
browser.startup.homepage_override.buildID: 20141028030204
browser.startup.homepage_override.mstone: 36.0a1
browser.tabs.remote.autostart: true
dom.ipc.plugins.reportCrashURL: false
dom.max_script_run_time: 0
dom.mozApps.used: true
dom.serviceWorkers.enabled: true
extensions.lastAppVersion: 36.0a1
font.internaluseonly.changed: true
font.size.variable.x-western: 20
gfx.direct3d.last_used_feature_level_idx: 1
gfx.font_rendering.directwrite.enabled: true
gfx.layerscope.enabled: true
layers.acceleration.force-enabled: true
media.gmp-gmpopenh264.enabled: true
media.gmp-gmpopenh264.lastUpdate: 1412184250
media.gmp-gmpopenh264.path: C:\Users\PC-Admin\AppData\Roaming\Mozilla\Firefox\Profiles\3azmrd7z.default\gmp-gmpopenh264
media.gmp-gmpopenh264.version: 1.1
media.gmp-manager.lastCheck: 1414520512
network.cookie.prefsMigrated: true
places.database.lastMaintenance: 1414520502
places.history.expiration.transient_current_max_pages: 70499
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
plugin.state.flash: 1
plugin.state.npctrl: 1
plugin.state.nppdfxcviewnpplugin: 2
plugin.state.npvlc: 1
privacy.cpd.cookies: false
privacy.cpd.downloads: false
privacy.cpd.extensions-sessionmanager: false
privacy.cpd.formdata: false
privacy.cpd.history: false
privacy.cpd.sessions: false
privacy.sanitize.migrateFx3Prefs: true
privacy.sanitize.timeSpan: 0
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1412014709

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.10.7
Version in use: 4.10.7

NSS
Expected minimum version: 3.18 Basic ECC Beta
Version in use: 3.18 Basic ECC Beta

NSSSMIME
Expected minimum version: 3.18 Basic ECC Beta
Version in use: 3.18 Basic ECC Beta

NSSSSL
Expected minimum version: 3.18 Basic ECC Beta
Version in use: 3.18 Basic ECC Beta

NSSUTIL
Expected minimum version: 3.18 Beta
Version in use: 3.18 Beta

Experimental Features
---------------------

Name: Invisible test of the experiment branching system.
ID: experiment-branch-test-nightly@experiments.mozilla.org
Description: An experiment using branches just to test whether branches get saved correctly.
Active: false
End Date: 1409612858674
Homepage:

Name: tile switcher
ID: tile-switcher@experiments.mozilla.org
Description: An add-on which switches the location of NewTab tiles.
Active: false
End Date: 1398520881403
Homepage:

	Nicholas Nethercote [inactive]
	Comment 6 • 10 years ago

> The problem is not that PDF.js uses a huge amount of memory but from an
> architectural point of view and for the sake of performance and stability it
> will be better that firefox fires a new container for every newly opened PDF
> document

Firefox's use of pdf.js means that PDFs aren't really any different from any other web content tabs -- it's just HTML and JavaScript doing the rendering.

So this bug basically boils down to the question "what is the right number of web content processes?" That question has multiple possible answers, and there are advantages and disadvantages to each answer, but my understanding is that when e10s is enabled the initial answer will be "one" and it may be raised later, carefully. But I don't think this bug is the right place to discuss this question.

Also, in its current form this bug is misleading, because pdf.js isn't using a lot of memory for this example PDF. Plus, we have a bug about pdf.js memory usage (bug 881974).

So I think this bug should be closed. Sound reasonable?

	ferongr
	Comment 7 • 10 years ago

Would it be reasonable to spawn a new process just for pdf.js when a pdf is opened and terminate it when the last pdf.js "window" is closed? In theory (since pdf.js usually does take a lot of memory) this would prevent heap fragmentation and also prevent 32-bit system from hitting address space limits.

	Achwaq Khalid Reporter
	Comment 8 • 10 years ago

(In reply to ferongr from comment #7)
> Would it be reasonable to spawn a new process just for pdf.js when a pdf is
> opened and terminate it when the last pdf.js "window" is closed? In theory
> (since pdf.js usually does take a lot of memory) this would prevent heap
> fragmentation and also prevent 32-bit system from hitting address space
> limits.

@Nicholas Nethercote this is somehow my main idea although 

In it's current state firefox won't create a new plugin-container unless it's stated in About:Config which requires restarting the browser! what i'm suggesting is to fire a new plugin-container for every newly opened PDF file and close it whenever it's tab is closed while ignoring the ProcessCount

PDF documents with rich graphic content sometimes really stress the browser and in laptops this can turn into a struggle

	Achwaq Khalid Reporter
	Comment 9 • 10 years ago

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #2)
> Achwaq, does that summary capture the problem? If so, do you have any addons
> installed? Also, have you changed the number of processes? More than one
> content process isn't well supported yet.

As stated by Nicholas Nethercote "in its current form this bug is misleading, because pdf.js isn't using a lot of memory for this example PDF. Plus, we have a bug about pdf.js memory usage (bug 881974)." I also don't think that the current name serves the purpose of this bug

	Nicholas Nethercote [inactive]
	Comment 10 • 10 years ago

I've updated the bug title to match (I hope) the descriptions in comment 4, comment 7 and comment 8.

Again, I don't think pdf.js tabs are notable different from other tabs -- non-pdf.js tabs can easily stress the browser just as much or more -- but I've set the "tracking-e10s" flag so the e10s people can make that decision. Either way, this doesn't need the "MemShrink" tag any more.

	Tony Mechelynck [:tonymec]
	Comment 11 • 10 years ago

The tendency seems to be to share subprocesses rather than multiply them, see bug 641685 (which, IIUC, is about NPAPI plugin-container processes, including Acrobat Reader tabs but not PDF.js tabs).

	Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧
	Comment 12 • 10 years ago

(In reply to Tony Mechelynck [:tonymec] from comment #11)
> The tendency seems to be to share subprocesses rather than multiply them,
> see bug 641685 (which, IIUC, is about NPAPI plugin-container processes,
> including Acrobat Reader tabs but not PDF.js tabs).

I think the original motivation there might have been more about NPAPI plugins not expecting to have multiple instances running concurrently within the same browser instance.  Also, sandboxing changes the landscape here — content processes need to stop creating their own child processes directly (especially NPAPI, because plugins typically need unrestricted access to the system), and multiple content processes can limit the impact of a content process compromise.