1900594 - Visual progress tracks for lastVisualChange profiles are broken

Status: NEW

(Testing :: Raptor, defect, P2)

Description

[Andra Esanu (needinfo me)]

We don't have markers for lastVisualChange in the profiles, but we should be able to use the visual progress tracks to find where the last visual change was - however those are broken in these profiles.

Comment 1

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

Could you please share an example profile link where it's broken?
Can you also elaborate on what you mean by "broken"? Were they always missing, or did we have markers for lastVisualChange at some point in the past that are now not working anymore?

Comment 2

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

Attachment: null-visualprogress-timestamps.png

Okay, I found one profile from matrix today and the visual progress tracks indeed look broken. They don't have any progress in them and they always look like they are 100%.
Here's an example profile: https://share.firefox.dev/3x56qHI

Looking into the profile json, it looks like all the timestamps have null values. So this is most likely a regression from browsertime.

To look at it yourself, you can load the profile above and open the devtools web developer console then type this: profile.meta.visualMetrics. This should show the data that came from browsertime. And if you look into either ContentfulSpeedIndexProgress, PerceptualSpeedIndexProgress, or VisualProgress; their timestamps are all null. See the attached screenshot as well.

Comment 3

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

Ah it seems like there is a bug on browsertime about this already: https://github.com/sitespeedio/browsertime/issues/1746
It's unclear to me where exactly the problem is from reading the issue though. It might need some more investigation.

Comment 4

[Andra Esanu (needinfo me)]

Hi! Maybe :sparky can give more details about this.

Comment 5

[Greg Mierzwinski [:sparky]]

I'm thinking it's because of the lack of using the firefox window recorder on the windows platform. On other platforms we use it, and there are no issues with the timestamps/tracks based on linux/mac from what I've seen so far. Based on that the issue could be here, where the timestamps for one of these is not defined when we use ffmpeg for recording: https://github.com/sitespeedio/browsertime/blob/e85cbd42890959a9225839288aec6fd33de0d3ac/lib/firefox/webdriver/firefox.js#L339-L342