Prior art that we might want to adopt and then leapfrog: https://developer.chrome.com/extensions/system_memory Additionally, note that a JSM is being developed in bug 1255843 which should add some useful shortcuts for getting memory measurements for content processes. This experimental API could perhaps use that JSM instead of talking to the nsIMemoryReporterManager directly. Use cases for this API include: 1) Getting notifications about things like memory pressure so that WebExtensions can attempt to clear caches 2) Adding UI to Firefox to report detailed memory usage statistics More futuristically, billm also talked at one point about a separate experimental WebExtension API for helping Firefox decide which content process to open particular tabs in for e10s-multi. Memory usage data might be useful for making such decisions in that theoretical API.
In case it's relevant: xpcom/base/nsIMemory.idl has some stuff related to memory pressure notifications.
Hi Nick, is someone on your team interested in doing something in this area?
Priority: -- → P2
Whiteboard: [experiments] triaged
Note that this was an idea that billm proposed in London, and I wanted to make sure it wasn't forgotten.
Severity: normal → enhancement
(In reply to :shell escalante from comment #2) > Hi Nick, is someone on your team interested in doing something in this area? I'm not 100% sure this really was intended to be for me, but in case it was: sorry, not at the moment.
I put together a draft of a WebExtension experiment at: https://github.com/EricRahm/memory-api-experiment It includes a `getInfo` method that's just a pass-through to `Memory.summary`, so that means it just includes rss and uss for all processes. What's nice is we can update Memory.jsm to add more info without messing the WebExtension API (I have a draft patch for adding ghost window counts). Addtionally it has an `onLowMemory` event that hooks into the internal 'memory-pressure' event. I explicitly didn't add 'total system memory' and 'system memory used' because a) we don't have a reporter for that currently and b) I'm not sure that'd pass the privacy test. mconley would you mind providing some feedback on what I have implemented or helping me find a more appropriate reviewer?
Assignee: nobody → erahm
Status: NEW → ASSIGNED
I like it - I also like that we're considering exposing more than the Chromium API. It gets a thumbs up from me - though you'll probably want to talk to the WebExtensions team in general to try to get this integrated. They're the deciders on what gets adopted as official APIs. Tentatively redirecting to :aswan to see if he has any feedback.
Flags: needinfo?(mconley) → needinfo?(aswan)
From a quick glance, this looks good, thanks! What's the longer-term plan here? Should we land this directly in central so that extensions can use it without having to install a separate experiment? (I or somebody else should take a more careful look through the implementation if we're going to do that, but from a high level there aren't any glaring problems)
I removed Memory.jsm in bug 1474990, here is a link to the changeset for future reference if you need to re-add it here: https://hg.mozilla.org/mozilla-central/rev/6ee592ecc6ac
Whiteboard: [experiments] triaged → [experiments][triaged][dev-ux]
You need to log in before you can comment on or make changes to this bug.