1331135 - Performance User Timing entry buffer restricted to 150

Status: RESOLVED DUPLICATE of bug 1159003

(Core :: DOM: Core & HTML, defect, P1)

Description

[Nolan Lawson]

Attachment: Reproducible test case

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Edge/15.15010

Steps to reproduce:

1. Go to http://bl.ocks.org/nolanlawson/663cc7e70a6258de759a59fd4b5e559b



Actual results:

`performance.getEntriesByType('mark')` returns 150 results


Expected results:

It should return 1000 results, because that's how many marks were added. Chrome 55 and Edge 14 both have this behavior.

This seems to be either a misreading of the spec, a spec bug, or potentially a webcompat bug. While the spec says that Resource Timings can be limited to 150, what Firefox appears to be doing is limiting _all_ timings (including Resource and User Timings) to 150. If you add your own custom marks and measures, you will quickly run up against this limit, whereas for Chrome and Edge/IE it seems to be unlimited.

See also relevant discussion on GitHub: https://github.com/w3c/resource-timing/issues/89

Comment 1

[Nolan Lawson]

I'll add that `performance.setResourceTimingBufferSize(100000)` fixes this issue, which seems odd since the API name implies it should only apply to Resource Timings, not User Timings. Although both MDN and the spec seem a bit ambiguous (unless I'm not reading something correctly):

- https://developer.mozilla.org/en-US/docs/Web/API/Performance/setResourceTimingBufferSize
- https://w3c.github.io/resource-timing/#dom-performance-setresourcetimingbuffersize

Comment 2

[:Harald Kirschner :digitarald]

This could block use cases like React's devtools markers [1], which extensively marks component lifecycle methods to be displayed in a flamegraph.

Comment 3

[Andrew Overholt [:overholt]]

Hiroyuki, can you take a look?

Comment 4

[Hiroyuki Ikezoe (:hiro)]

I've filed about this concern before.  Bug 1159003.
Even though the current value, 150 is too small, but bz suggested that it should be limited.  Please see bug 1159003 comment 1.

Comment 5

[:Harald Kirschner :digitarald]

Discussion also happens in https://github.com/w3c/resource-timing/issues/89 . The tendency is not going unlimited but choosing a limit that meets common use cases.

Comment 6

[Nolan Lawson]

FWIW both Ilya and I believe this is a spec bug: https://github.com/w3c/resource-timing/issues/89#issuecomment-283463782

Also Firefox's behavior is not consistent with Chrome's or Edge's, which may lead to webcompat bugs: https://github.com/w3c/resource-timing/issues/89#issuecomment-283428246

Comment 7

[Nolan Lawson]

Sorry for the ambiguity; by "spec bug" I meant "Firefox's behavior is not consistent with the spec."

Comment 8

[Nolan Lawson]

FWIW, I just ran into this bug again due to the popular "react-addons-perf" tool, which triggers the issue very consistently because they don't make any attempt to increase Firefox's buffer size: https://github.com/tootsuite/mastodon/pull/3315

This seems like a compat bug that could be fixed by simply changing a constant (i.e. upping 150 to 10000 or 100000 or ideally Infinity to match Chrome/Edge's behavior). Hope y'all will look into this! :)