Feedback from GSuite & Gmail

[erikchen]

Tim, Hannes and I spoke with the GSuite & Gmail teams offline. They were happy with the introduction of PrivateMemoryFootprint, but had concerns about the "accurate or null" proposal. Their concern was that their properties might disproportionately end up in the "null" bucket, due to usage patterns of their users.

They suggested the following:

• Assuming that there are a process contains multiple top level frames from the same origin...
• Continue to report stats [knowing that they will be inflated]
• But also include: numberOfSharedRenderers

Users that want the "accurate or null" property can simply ignore results with numberOfSharedRenderers > 1.

There's a slight caveat - as per discussion with Boris Z on blink-dev@chromium, we will actually need to report:

• numberOfNonEmptyFrameTrees

which has different semantics, but will usually provide a similar result. This seems like a reasonable request.

Tim, Hannes and I brainstormed how to appropriately change the API to support this without introducing a foot-gun. It seems likely that some developers will accidentally ignore the numberOfNonEmptyFrameTrees field and get incorrect results.

We failed to come up with an answer that wasn't too clunky, so we're going to just drop in the field for now, and consider the ergonomics later.

[erikchen]

If we're going to expose non-null stats when numberOfNonEmptyFrameTrees > 1, I wonder if we should just expose the URL of each frame in the process. This information is already available via the following mechanism:

At a fixed point in time, each frame from <Origin A> creates a cookie, and sets the URL of the top-level frame, along with performance.memory.jsHeapSize. Then each frame from can look for all cookies from <Origin A>, and if the jsHeapSize is very close to the jsHeapSize set by the frame, then that cookie [and corresponding frame] and most likely being hosted in the same process.

[erikchen]

Tim points out that the former information leakage requires active participation from same-origin frames, which seems to not be a major concern. But exposing URLs of frames now removes the "active participation" requirement, which is undesirable for external-content hosting origins.

[erikchen]

This pull request updates the spec to add a numberOfTabs property.

[erikchen]

The GSuite team wrote a document describing their uses of Chrome's existing performance.memory API, and their feature requests for a standardized API.