Closed Bug 1813599 Opened 1 year ago Closed 1 year ago

PerformanceMark may expose a non-reduced timestamp

Categories

(Core :: DOM: Performance, defect)

defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox-esr102 --- unaffected
firefox109 --- unaffected
firefox110 --- unaffected
firefox111 --- affected

People

(Reporter: tjr, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Simon noted here that performance mark seems to be exposing 1ms precision timestamps; when it should be respecting RFP. Needs investigating..

Set release status flags based on info from the regressing bug 1811567

:tjr could you set a severity on this, wondering what the impact is on 111?

Flags: needinfo?(tom)

I'll make it S2, but it can be downgraded to S3 I think if I find myself unable to get to it halfway through 111 beta.

Severity: -- → S2
Flags: needinfo?(tom)

I think we are doing the right thing, and TZP is wrong.

From https://github.com/arkenfox/TZP/blob/bc627f9d16c6fcf9f4f9488723c7e99a3758bb82/js/misc.js#L363-L368

if (isFF && isTZPSmart) {
		let ctrlM = isVer > 110 ? 4 : 0
		notation = testE == ctrlE && testM == ctrlM ? rfp_green : rfp_red
	}
	dom.perf1.innerHTML = testE +" | "+ testM + notation

testM is the performance.measure.length and it is 4.

testE is the length of different mark arrays. There are mark entries. However ctrlE is let ctrlE = "0, 0, 0, 0" - it's saying there shouldn't be any entries.

That explains the red RFP string. The list 1, 4, 4, 1 is not timestamps, and when I look at timestamp values from mark - they appear correctly clamped like performance.now().

Flags: needinfo?(simon.mainey)

The list 1, 4, 4, 1 is not timestamps

honestly, I wrote that like 4 years ago. I've clearly forgotten it's original purpose - which was checking entries in various ways. The 1,4,4,1 seemed plausible as ms: it's just four rapid getEntries (but as .length). mea culpa

Now RFP enables the API and returns entries, I need to change the test. Closing as invalid, will update test. If I find it's still broken (unlikely), I'll reopen, otherwise consider this dealt with

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(simon.mainey)
Resolution: --- → INVALID

OK, now I've had some coffee ... the penny drops ... of course I wasn't ever checking actual timing (because RFP disabled it), the original test was checking that it was disabled! FF110+ FF111+ will instead test for actual timing

You need to log in before you can comment on or make changes to this bug.