Bug 1807506 Comment 3 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Rob Wu [:robwu] from comment #2)
> What are the use cases for this API? What we're actually looking for here is to see whether there is functionality not possible without this API.

I wrote this patch because because my school uses ProctorU. ProctorU is very common (in the United States, at least) and I do think web compatibility is enough of a justification. I can try to think of some use cases, let's see:

* An extension could decide whether or not to do some memory intensive operation based on this info. e.g. If the user only has 4 gigabytes of ram, use the disk instead of memory to prevent crashing the browser. 
* An extension could use this information to tune heuristics for when to flush a cache.
* I could see this being useful for extensions that maintain a lot of state (I'm vaguely imagining something with video) that want to decide if they should recompute that state or store it in memory. (Service workers/non-persistent background pages).
* There's probably someone out there that wants/needs to aggressively reduce Firefox's memory usage. So I can imagine someone creating an extension that uses this info to augment the existing memory unload heuristics built into Firefox and discard tabs. Imaginary scenario (involves bug 1809094): An extension that adds a tab context menu item to prevent unloading of a tab. This extension includes ability to optionally ignore the user, and reset their choice, if ` availableCapacity` is below some arbitrary number.

That said, I'm not a creative person at all, and it's possible I'm missing some obvious use case.
(In reply to Rob Wu [:robwu] from comment #2)
> What are the use cases for this API? What we're actually looking for here is to see whether there is functionality not possible without this API.

I wrote this patch because my school uses ProctorU. ProctorU is very common (in the United States, at least) and I do think web compatibility is enough of a justification. I can try to think of some use cases, let's see:

* An extension could decide whether or not to do some memory intensive operation based on this info. e.g. If the user only has 4 gigabytes of ram, use the disk instead of memory to prevent crashing the browser. 
* An extension could use this information to tune heuristics for when to flush a cache.
* I could see this being useful for extensions that maintain a lot of state (I'm vaguely imagining something with video) that want to decide if they should recompute that state or store it in memory. (Service workers/non-persistent background pages).
* There's probably someone out there that wants/needs to aggressively reduce Firefox's memory usage. So I can imagine someone creating an extension that uses this info to augment the existing memory unload heuristics built into Firefox and discard tabs. Imaginary scenario (involves bug 1809094): An extension that adds a tab context menu item to prevent unloading of a tab. This extension includes ability to optionally ignore the user, and reset their choice, if ` availableCapacity` is below some arbitrary number.

That said, I'm not a creative person at all, and it's possible I'm missing some obvious use case.

Back to Bug 1807506 Comment 3