1469338 - Write a jank test for SQL operations blocked on transactions completing on a background thread

Status: NEW

(Toolkit :: Places, defect, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

mak and I discussed this briefly in SF.

There was some kind of regression recently where it was suddenly possible for the main thread to get blocked while waiting for an SQLite transaction on a background thread to complete for some Places stuff.

Unfortunately, we didn't find that problem until pretty late - beta, I think - and we were pretty fortunate to find it, as I understand.

So mak and I were talking about ways we could try to prevent or head off these kind of regressions sooner in the future. A few ideas:

1. We need the slow SQL query telemetry back. Apparently, clients are now reporting this (after briefly not reporting it after a Telemetry refactor), but we don't currently have any UI to display the data.

2. Write regression tests for the common user interaction patterns that might result in jank.

Traditionally, we've used Talos for (2), but there might be a simpler way. The type of performance tests we've been developing under browser/base/content/test/performance might be the template to follow here.

Supposing we have some Places thing we want to test for jank, what I suggest is to queue up a requestAnimationFrame, and have the passed function check to see if the test has completed. If not, record the time since the last requestAnimationFrame was serviced, and start collecting deltas.

Deltas over 16ms probably indicate jank, although I'd recommend such tests test for things that jank for things in tens or hundreds of milliseconds. I suspect that attempting to detect 1 frame of jank in the test might result in a bunch of false positives from unrelated things.