Comment 6 for bug 1576639

First of all: I agree with the original bug report, relying on % of total system memory is likely to over- or under-estimate the actual memory situation. A short-term solution would be to select a fixed threshold in accordance with the OOM setup configured on our kernels, thus avoiding the issues presented in #2. Mid-term, I would propose two adjustments:

(1.) The system should let applications know if a low-on-memory situation is encountered, enabling the app to free up memory *before* the kernel OOM handler kicks in.
(2.) For the browser specifically: We should fine-tune how memory is freed up/tabs are torn down. "Least recently used" is an obvious choice, but we should also factor in if a tab is playing audio/video or actively accessing the camera/microphone and adjust likelihood of being killed accordingly.

(1.) and (2.) together should solve the issue in a way that handles memory pressure situations as gracefully as possible.