1606365 - [Browsertime][WebRender] Orange frame still persists after the navigation has started

Status: RESOLVED WORKSFORME

(Testing :: Performance, defect, P3)

Description

[Sean Feng [:sefeng]]

Attachment: browsertime.MOV

Check around 5 seconds of the video, you can see the navigation had started, but the orange frame was still persist. This was Fenix running Moto G5. (also reproducible on Pixel 3)

This only occurs when WebRender is enabled.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Jessie - Can you get someone on the WR android team to take a look at this? Perhaps the visual update from removing the DOM orange frame before starting the navigation is getting delayed?

For reference, browsertime uses this (browsertime/lib/core/seleniumRunner.js) to make the orange frame's removal mark the the start of a load:

 const navigate = `(function() {
     const orange = document.getElementById('browsertime-orange');
     if (orange) {
       orange.parentNode.removeChild(orange);
     }
     window.requestAnimationFrame(function(){
       window.requestAnimationFrame(function(){
         window.location="${url}";
       });
     });
   })();`;

Comment 2

[Kris Taeleman (:ktaeleman)]

Jamie: Do you think this could be related to the black screen issues we've been seeing?

Comment 3

[Jamie Nicol [:jnicol] out of office until 6th Jan]

It sounds plausible, yes. I'll investigate.

Sean or Randell, I've never used browsertime before. Would it be possible to give a slightly more detailed STR?

Comment 4

[Sean Feng [:sefeng]]

Hi Jamie,

In latest m-c, you should be able to do ./mach browsertime --setup, and it will install browsertime for you, please make sure the output says

ffmpeg:   OK
convert:  OK
compare:  OK
Pillow:   OK
SSIM:     OK

And then you can use this command to reproduce it. You need to install the performanceTest apk to your phone, you can get it here

./mach browsertime -- --android -b firefox --firefox.android.package org.mozilla.fenix.performancetest --video true --visualMetrics true --firefox.android.intentArgument=--ez --firefox.android.intentArgument=TURBO_MODE --firefox.android.intentArgument=false --firefox.android.intentArgument=-a --firefox.android.intentArgument=android.intent.action.VIEW --firefox.android.intentArgument=-d --firefox.android.intentArgument="data:," --firefox.windowRecorder false --firefox.android.activity org.mozilla.fenix.browser.BrowserPerformanceTestActivity -n 1 https://ebay.com

Comment 5

[Jessie [:jbonisteel] pls NI]

We theorize this should be addressed by bug 1581868

Comment 6

[Jeff Muizelaar [:jrmuizel]]

FWIW, I don't think this is related to the black screen issue. I think it should probably be debugged separately.

Comment 7

[Jessie [:jbonisteel] pls NI]

I spoke too soon!

Comment 8

[Jeff Muizelaar [:jrmuizel]]

We worked around this by adding a white div behind the orange one.

Comment 9

[Kris Taeleman (:ktaeleman)]

Changing the priority of the bug due to workaround unblocking browsertime.

Comment 10

[Sean Feng [:sefeng]]

For the record, this is the workaround https://github.com/mozilla/browsertime/pull/60

Comment 11

[Greg Mierzwinski [:sparky]]

:jnicol, there's an outstanding ni? in this bug from :sefeng - has it been answered?

Comment 12

[Jamie Nicol [:jnicol] out of office until 6th Jan]

I don't think the needinfo was asking anything, but instead was just to ensure I saw Sean's answer. So yes.

(I think I was able to reproduce using Sean's instructions, but didn't investigate any further due to the workaround.)

Comment 13

[Greg Mierzwinski [:sparky]]

:sefeng, do you know if this is still an issue?

Comment 14

[Sean Feng [:sefeng]]

I removed the workaround we did in comment 10 from browsertime, and was unable to reproduce it by using the command from comment 4 against https://firefox-ci-tc.services.mozilla.com/tasks/index/mobile.v2.fenix.beta.2020.09.23.latest.

So looks like this is not an issue anymore.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Can you remove the workaround from upstream browsertime?

Comment 16

[Sean Feng [:sefeng]]

The workaround is now removed from the upstream https://github.com/sitespeedio/browsertime/pull/1821#issuecomment-1207272316