1629868 - No support for the navigator.deviceMemory property

Status: NEW

(Core :: DOM: Core & HTML, enhancement)

Description

[robin]

User Agent: Mozilla/5.0 (Android 7.1.1; Mobile; rv:68.0) Gecko/68.0 Firefox/68.0

Steps to reproduce:

After checking the support for the navigator.deviceMemory property by doing a simple console.log("navigator.deviceMemory"); in a test Javascript file on a dummy web page, I've come to the conclusion that it is not yet supported.

Actual results:

This simple code returned "undefined" in both Firefox 75.0 64bits and Firefox Developer Edition 76.0b4 64bits. This test has been done on the following PC:

CPU: AMD K10 model unknown - 6 physical cores overclocked @ 3.7Ghz.
RAM: 16GB DDR3 1600Mhz CL9
GPU1&2: AMD Radeon HD6870 X2 2GB (radeon/xf86-video-ati)
GPU3: Nvidia Quadro K600 1Go (nouveau)
OS: ArchLinux 64bits running on Linux Lts 5.4.31-1

Expected results:

If Firefox supported this feature, it should have returned the amount of memory (RAM) that the computer has, so 16GB in this case. I understand that some people may think that this feature can be a privacy concern in some cases but it helps developers to better understand the capabilities of the client to propose the best experience. I think that it should be implemented in Firefox as blink based browsers supports it. Maybe it should continue to return "undefined" in private windows for privacy.

Comment 1

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 2

[Marcel Duran]

Any updates on this? I wonder if this is the master bug or just an untriaged duplicate.
Device memory information has been used lately as good enough proxy for user device power/capability. It allows features to be installed/registered conditionally, avoiding overloading low end devices for example.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

Continuing the discussion from https://bugzilla.mozilla.org/show_bug.cgi?id=1728741#c15

add a deviceMemory in navigator shim and always report e.g. 512MB for desktop and e.g. 256MB for android (made up values), noting that we can't hide the platform

FYI I proposed 2GB and 512MB here in a pull request to the affected site: https://github.com/ornicar/lila/pull/10190

Comment 4

[Gian-Carlo Pascutto [:gcp]]

it helps developers to better understand the capabilities of the client to propose the best experience.

One of the concerns - which also applies to WebGL queries for GPU RAM - is that this informs the developer what the device has, but it is actually meaningless for how much the application on the webpage can use without being disruptive or being disrupted. After all, it's deviceMemory, not freeMemoryYouCanUseWithoutSwapping or something similar. So it likely encourages bad design decisions.

Comment 5

[robin]

One of the concerns - which also applies to WebGL queries for GPU RAM - is that this informs the developer what the device has, but it is actually meaningless for how much the application on the webpage can use without being disruptive or being disrupted.

Right, but the memory that appears to be free is something thant constantly changes significantly because of user actions but also background tasks including those that only uses free memory like superfetch for example. It is almost impossible to predict sharply the maximum memory amount the running processes will use in a near future so it is more than a challenging task to design an app that will almost fill the free memory in real time, on every platform, without swapping.
Many desktop apps uses the amount of memory the task requires regardless of what the machine has, and most apps that care a bit more about user experience just autoset themselves to use at most a safe computed amount of system memory, leaving to the user the task to make sure it is free as long as the program is running.
For web apps, such a property will at least empower developers to use a "safe" amount of the system memory by default, and eventually a more "restrictive" amount of RAM for demanding tasks after warning the user about it so he can close tabs and apps running in the background if necessary to let the task run flawlessly.
I don't know what is your use case, but even though you will retrieve the amount of system memory with ease, determining the "safe" and "restrictive" thresholds will still be challenging as every target system has it's own requirements. Using analytics on end devices these values can be efficiently predicted statistically according to your user setups and habits, and eventually fine tuned in place with benchmarks if performance does not seems to meet your standards. This is certainly the way I would take.

Comment 6

[Gian-Carlo Pascutto [:gcp]]

I don't know what is your use case

The use case above was allocating some extra memory buffers to make a chess engine faster (trading memory usage for extra speed). In the end, if we can't share the memory for privacy reasons, the site can just use the same logic as above and infer from what it can see from the browser what a reasonable amount is, so in the end that site will no longer need this as they worked around it this way.

We can ask Marcel what his use case was.

For a very similar story in the context of GPU memory, see:
https://bugzilla.mozilla.org/show_bug.cgi?id=1715690
https://bugzilla.mozilla.org/show_bug.cgi?id=1730846

Any maybe we can even draw analogies to the (even more flawed) habit of triggering features based on UA strings, the exposing of which is definitely considered a fatal mistake these days.

Comment 7

[Marcel Duran]

In my use case, deviceMemory is a signal for adaptive content strategies to better optimize user experience based on their device's capability. In cases where heavy processing is required, deviceMemory demonstrated a much more reliable signal than others like hardwareConcurrency, i.e. the higher the device memory the lesser the top level metrics regression. E.g.: ServiceWorker performed better start up time the larger the device memory, regardless of the number of logical processors, which consequently impacted DAU.

The deviceMemory information is similar to other device information currently supported by Firefox, e.g. hardwareConcurrency. They state the device's memory physical size and number of logical processors but do not inform how many of those are available (if any) for usage. This is arguably similar to screen.width and height, where it's useful to check the minimum screen size before running a given task. It does not inform how much of the screen area is available at that moment, but the device has a minimum screen size to perform such task.

This is particularly true for Desktop where the minimum device memory can't be inferred from other weaker signals such as UA. E.g.: iPhone 13 will always be 4GB RAM & 6 cores.

This Smashing Magazine analysis shows the correlation between deviceMemory and WebVitals metrics