Fenix: [Bug] Long delay when pressing URL bar while having a tab open

[hwinnemoe]

Steps to reproduce

1. Open a website and wait for it to load
2. Make sure that the bottom bar is visible
3. Tap on the URL bar

Expected behavior

The URL bar should immediately move to the top of the screen and the keyboard becomes visible.

Actual behavior

A long delay (over 1 second) is perceived until the URL bar moves to the top of the screen. This delay is not present when tapping the URL bar while being in the tab tray/list.

Device information

• Android device: 6.0.1, Sony Xperia Z2
• Fenix version: Nightly 200226 18:00 (Build #20571806) 34.0.0, 03451de2e GV: 75.0a1-20200225094028

[AaronMT]

(@boek MLS bug?)

[boek]

@AaronMT yes! Will investigate nightly

[mcomella]

This isn't the MLS bug: the MLS issue happens only the first time the URL bar is pressed and is #9935. This issue happens every time.

I started to investigate and took a profile (iirc, on my P2): https://share.firefox.dev/30SjayZ Interesting things initially:

• From dispatchTouchEvent to inflating the view, there's a 100ms delay but nothing relevant & significant appears to happen during that time. It's as if there is a scheduling delay
• After we layout & draw, consumeFrom runs and we do another layout + draw: I wonder if this delays anything (this seems like an anti-pattern: we should run this synchronously if possible)
• showKeyboard gets called in a loop: how does this affect the performance of this view?

[mcomella]

I took a profile on my GS5: https://share.firefox.dev/37SL2of

It appears we're launching a coroutine on a background thread to capture a thumbnail and don't continue on the main thread until it completes. This is backed up by the profile visual where we do onClick, the compositor executes for a while, and we begin main thread execution:

Here's the code where we capture a thumbnail:
https://searchfox.org/mozilla-mobile/rev/f1f9880935a87f0dbdc9d107a9067dbd73338b96/fenix/app/src/main/java/org/mozilla/fenix/browser/BrowserAnimator.kt#123-136

[mcomella]

I moved onComplete outside the captureThumbnail block and commented out that block and I can confirm the long pause is removed.

Anecdotally, it feels faster on my GS5 (about the same on the P2) and I never suffer intermittent long delays though it's still slower than I'd like.

I filed https://github.com/mozilla-mobile/fenix/issues/11825 to fix this issue.

[mcomella]

@hwinnemoe We fixed one cause of this issue – are you still experiencing this problem?

[mcomella]

@hwinnemoe We fixed one cause of this issue – are you still experiencing this problem?

I meant, are you still experiencing this problem in the latest nightly?

[hwinnemoe]

I meant, are you still experiencing this problem in the latest nightly?

It has improved a lot in the latest nightly, thanks. There is still some delay compared to the instant reaction of Fennec and Chrome (Production). Should we leave this open then?

[mcomella]

There is still some delay compared to the instant reaction of Fennec and Chrome (Production). Should we leave this open then?

I have experienced this as well and I want to make it better - let's leave this open and I'll continue to investigate. :)

[mcomella]

Unassigning: we're primarily looking at startup right now.

[hwinnemoe]

This has regressed again on Nightly 200807 06:01 (Build #2015756529), maybe earlier. Switching to the new search experience yields better results, so maybe we should wait for the new search experience to be finished before we start investigating this again?

[mcomella]

so maybe we should wait for the new search experience to be finished before we start investigating this again?

That makes sense to me – I'll add a note to our triage board about this regression to remind us just in case the new search experience back pedals and uses some old code.

[mcomella]

@hwinnemoe Do you still see the slow behavior with the new search experience?

[hwinnemoe]

Fenix Nightly (201028 17:00) is still noticeably slower compared to Chrome (86.0.4240.110), but not as slow as this issue was originally created for. The new search experience has introduced an issue of _perceived_ performance though: see #14246 which I can reproduce regardless of the device I'm using.