[Webkit-unassigned] [Bug 221901] New: Resource Timing API won't clear entries & misses some requests.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=221901

            Bug ID: 221901
           Summary: Resource Timing API won't clear entries & misses some
                    requests.
           Product: WebKit
           Version: Safari 14
          Hardware: Mac (Intel)
                OS: macOS 10.15
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: arshankhanifar at gmail.com

There are two problems I have identified with resource timing API on safari:
1. not every request gets measured.
2. even after clearing the performance timing buffer, it acts as if it is full, and won’t return any new measurements.

I have created this fiddle to show this:
https://jsfiddle.net/arshankhanifar/yeqhL21j/8/

I have two buttons:
1. the first button keeps making requests until the buffer is filled.
2. the second button clears the entries, so if the buffer was filled before, we expect to get new measurements.


ON CHROME:
When I run the fiddle in Chrome, the last line I see in console is:
```
"count", 254, "last_count", 254, "i", 276
```
This means:
1. max buffer size in chrome is defaulted to `254`
2. I end the loop when the number of the measurements has been the  same for more than `20` runs, this is due to (problem 1) with safari. And i shows the number of times the loop has run. So here, it shows that Chrome collected a measurement for every request since i is 254 + 20 (more or less, the counting may have some bug, on all runs this is usually 275 +- 1).

To repeat this, we can click “clear entries” and start the test again, and we’ll see that the numbers don’t change.


ON SAFARI:
On safari, this is the last line that I see on the first run:
```
"count", 150, "last_count", 150, "i", 219
```
Which basically means that about `50` requests were not measured. I can see that in the rest of the logs:
```
"count", 135, "last_count", 134, "i", 173
"count", 136, "last_count", 135, "i", 174
"count", 136, "last_count", 136, "i", 175 // repeated twice
"count", 137, "last_count", 136, "i", 176
```
Also, after clearing the entries and rerunning this here’s what I’m seeing:
```
"count", 85, "last_count", 85, "i", 540
```
This got worse now. Firstly, it didn’t even fill the buffer (it was 150 as shown in the first run), and also the ratio of i to count got much higher (around 85% of the requests were not measured).

And by repeating the “clear” & “run test” a couple more times:
```
"count", 0, "last_count", 0, "i", 21
```
It gets to a point where it doesn’t measure anything at all.


SAFARI - IOS:
This isn’t as bad with Safari on IOS - more requests are being dropped:
```
count – 150 – "last_count" – 150 – "i" – 306
```
But it doesn’t get worse with multiple runs. The buffer actually gets cleared.


CHROME - IOS:
This is way worse with Chrome on IOS: cap is at 51 requests, and buffer doesn’t get cleared.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210215/98b73e3e/attachment.htm>