Bug 2011967 Comment 3 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Thanks Daniel! I can reproduce it locally. Here are my findings:

Before Bug 1968204, this test was perma failing. The issue then was because of the rounding. The spec expected duration value to be the rounded to the multiplies of 8. 

The duration of event blocking is 300ms and the test expects 304 (as it's the rounded value to closest multiples of 8).
It looks like in the timing out case, this performance event timing entry is never firing. So `"duration of pointerdown event" >= 300` check is returning false somehow.

I put some printf values to see, and here's the failing case:

```
 0:05.27 pid:3577367 DispatchPendingEventTimingEntries: renderingTime=672.912660, startTime=373.236058, calculatedDuration=299.676602
 0:05.27 pid:3577367 EventTiming::SetDuration [pointerdown]: raw=299.676602, rounded=296.000000
 0:05.27 pid:3577367 DispatchPendingEventTimingEntries: renderingTime=672.912660, startTime=373.236058, calculatedDuration=299.676602
 0:05.27 pid:3577367 EventTiming::ShouldAddEntryToObserverBuffer [pointerdown]: rawDuration=296.000000, threshold=300.000000, result=0
```
So the tests blocks the main thread for 300ms, but we get `299.676602` as the duration for this event, which is lower than 300 threshold.

It looks like it's essentially because the expected duration is slower than the threshold, which ideally shouldn't happen. I'm not 100% sure what the best solution is though. We might be taking the start time too late?


This is where we get the start time (`aEvent->mTimeStamp`) : https://searchfox.org/firefox-main/rev/3eaf7e2acf8186eb7aa579561eaa1312cb89132b/dom/performance/PerformanceEventTiming.cpp#138 
This is where we get it the end time: https://searchfox.org/firefox-main/rev/3eaf7e2acf8186eb7aa579561eaa1312cb89132b/dom/performance/PerformanceMainThread.cpp#295,303
Thanks Daniel! I can reproduce it locally. Here are my findings:

Before Bug 1968204, this test was perma failing. The issue then was because of the rounding. The spec expected duration value to be the rounded to the multiplies of 8. 

The duration of event blocking is 300ms and the test expects 304 (as it's the rounded value to closest multiples of 8).
It looks like in the timing out case, this performance event timing entry is never firing. So `"duration of pointerdown event" >= 300` check is returning false somehow.

I put some printf values to see, and here's the failing case:

```
 0:05.27 pid:3577367 DispatchPendingEventTimingEntries: renderingTime=672.912660, startTime=373.236058, calculatedDuration=299.676602
 0:05.27 pid:3577367 EventTiming::SetDuration [pointerdown]: raw=299.676602, rounded=296.000000
 0:05.27 pid:3577367 DispatchPendingEventTimingEntries: renderingTime=672.912660, startTime=373.236058, calculatedDuration=299.676602
 0:05.27 pid:3577367 EventTiming::ShouldAddEntryToObserverBuffer [pointerdown]: rawDuration=296.000000, threshold=300.000000, result=0
```
So the tests blocks the main thread for 300ms, but we get `299.676602` as the duration for this event, which is lower than 300 threshold.

It looks like it's essentially because the expected duration is slower than the threshold, which ideally shouldn't happen. I'm not 100% sure what the best solution is though. We might be taking the start time too late?


This is where we get the start time (`aEvent->mTimeStamp`) : https://searchfox.org/firefox-main/rev/3eaf7e2acf8186eb7aa579561eaa1312cb89132b/dom/performance/PerformanceEventTiming.cpp#138 
This is where we get the end time: https://searchfox.org/firefox-main/rev/3eaf7e2acf8186eb7aa579561eaa1312cb89132b/dom/performance/PerformanceMainThread.cpp#295,303
Thanks Daniel! I can reproduce it locally. Here are my findings:

Before Bug 1968204, this test was perma failing. The issue then was because of the rounding. The spec expected duration value to be the rounded to the multiplies of 8. 

The duration of event blocking is 300ms and the test expects 304 (as it's the rounded value to closest multiples of 8).
It looks like in the timing out case, this performance event timing entry is never firing. So `"duration of pointerdown event" >= 300` check is returning false somehow.

I put some printf values to see, and here's the failing case:

```
 0:05.27 pid:3577367 DispatchPendingEventTimingEntries: renderingTime=672.912660, startTime=373.236058, calculatedDuration=299.676602
 0:05.27 pid:3577367 EventTiming::SetDuration [pointerdown]: raw=299.676602, rounded=296.000000
 0:05.27 pid:3577367 DispatchPendingEventTimingEntries: renderingTime=672.912660, startTime=373.236058, calculatedDuration=299.676602
 0:05.27 pid:3577367 EventTiming::ShouldAddEntryToObserverBuffer [pointerdown]: rawDuration=296.000000, threshold=300.000000, result=0
```
So the tests blocks the main thread for 300ms, but we get `299.676602` as the duration for this event, which is lower than 300 threshold.

It looks like it's essentially because the expected duration is lower than the threshold, which ideally shouldn't happen. I'm not 100% sure what the best solution is though. We might be taking the start time too late?


This is where we get the start time (`aEvent->mTimeStamp`) : https://searchfox.org/firefox-main/rev/3eaf7e2acf8186eb7aa579561eaa1312cb89132b/dom/performance/PerformanceEventTiming.cpp#138 
This is where we get the end time: https://searchfox.org/firefox-main/rev/3eaf7e2acf8186eb7aa579561eaa1312cb89132b/dom/performance/PerformanceMainThread.cpp#295,303
Thanks Daniel! I can reproduce it locally. Here are my findings:

Before Bug 1968204, this test was perma failing. The issue then was because of the rounding. The spec expected duration value to be the rounded to the multiplies of 8. 

The duration of event blocking is 300ms and the test expects 304 (as it's the rounded value to closest multiples of 8).
It looks like in the timing out case, this performance event timing entry is never firing. So `"duration of pointerdown event" >= 300` check is returning false somehow.

I put some printf values to see, and here's the failing case:

```
 0:05.27 pid:3577367 DispatchPendingEventTimingEntries: renderingTime=672.912660, startTime=373.236058, calculatedDuration=299.676602
 0:05.27 pid:3577367 EventTiming::SetDuration [pointerdown]: raw=299.676602, rounded=296.000000
 0:05.27 pid:3577367 DispatchPendingEventTimingEntries: renderingTime=672.912660, startTime=373.236058, calculatedDuration=299.676602
 0:05.27 pid:3577367 EventTiming::ShouldAddEntryToObserverBuffer [pointerdown]: rawDuration=296.000000, threshold=300.000000, result=0
```
So the tests blocks the main thread for 300ms, but we get `299.676602` as the duration for this event, which is lower than 300 threshold.

It looks like it's essentially because the expected duration is lower than the threshold, which ideally shouldn't happen. I'm not 100% sure what the best solution is though. We might be taking the start time too late? Or end too early?


This is where we get the start time (`aEvent->mTimeStamp`) : https://searchfox.org/firefox-main/rev/3eaf7e2acf8186eb7aa579561eaa1312cb89132b/dom/performance/PerformanceEventTiming.cpp#138 
This is where we get the end time: https://searchfox.org/firefox-main/rev/3eaf7e2acf8186eb7aa579561eaa1312cb89132b/dom/performance/PerformanceMainThread.cpp#295,303

Back to Bug 2011967 Comment 3