Closed Bug 1828927 Opened 2 years ago Closed 1 year ago

ANR in HomeFragment.applyWallpaper within runBlockingIncrement

Categories

(Firefox for Android :: General, defect, P2)

All
Android
defect

Tracking

()

VERIFIED FIXED
123 Branch
Tracking Status
firefox123 --- verified

People

(Reporter: jonalmeida, Assigned: rsainani)

References

Details

(Whiteboard: [fxdroid])

Attachments

(3 files)

This report doesn't seem to show up in Socorro, but can be see on the Play Console and looks pretty severe upon brief investigation: https://play.google.com/console/u/0/developers/7083182635971239206/app/4972519468758466290/vitals/crashes/e7efd36c26292d89e1e65f69d9b5ef99/details

~15K users affected in the last 28 days (as of today) on a range of devices, OS version and app version; started with Fenix 107.

org.mozilla.fenix.perf.RunBlockingCounterKt.runBlockingIncrement$default
at sun.misc.Unsafe.park (Native method)
at java.util.concurrent.locks.LockSupport.parkNanos (LockSupport.java:230)
at kotlinx.coroutines.BuildersKt.runBlocking (unavailable:122)
at kotlinx.coroutines.BuildersKt.runBlocking$default (unavailable:3)
at org.mozilla.fenix.perf.RunBlockingCounterKt.runBlockingIncrement$default (RunBlockingCounter.kt:33)
at org.mozilla.fenix.home.HomeFragment.applyWallpaper (HomeFragment.kt:81)
at org.mozilla.fenix.home.HomeFragment.onCreateView (HomeFragment.kt:284)
at androidx.fragment.app.Fragment.performCreateView (Fragment.java:20)
at androidx.fragment.app.FragmentStateManager.createView (FragmentStateManager.java:173)
at androidx.fragment.app.FragmentStateManager.moveToExpectedState (FragmentStateManager.java:118)
at androidx.fragment.app.FragmentManager.executeOpsTogether (FragmentManager.java:1138)
at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute (FragmentManager.java:92)
at androidx.fragment.app.FragmentManager.execPendingActions (FragmentManager.java:74)
at androidx.fragment.app.FragmentManager$5.run (FragmentManager.java:4)
at android.os.Handler.handleCallback (Handler.java:938)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:236)
at android.app.ActivityThread.main (ActivityThread.java:8056)
at java.lang.reflect.Method.invoke (Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:656)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:967)

The severity field is not set for this bug.
:jonalmeida, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(jonalmeida942)
Severity: -- → S2
Flags: needinfo?(jonalmeida942)
Priority: -- → P2

IIRC, we intentionally structured this as a runBlocking in order to eliminate visual startup jank on lower-end devices.

Basically, if we try to load the wallpaper asynchronously and then render it once loaded, the homescreen would render as the regular theme and then flash to the wallpaper. When I get time I'll double-check that, because if I'm remembering incorrectly this should be easy to fix.

(In reply to Matt Tighe [:matt-tighe] from comment #2)

IIRC, we intentionally structured this as a runBlocking in order to eliminate visual startup jank on lower-end devices.

These ANRs seem to be happening on fairly high end devices though (our baseline high device is the A53). Here are the top devices with how many affected users have them:

Device % from total affected
samsung r8q 3.5%
samsung a52sxq 2.2%
samsung b0q 1.8%
Assignee: nobody → rsainani
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch
See Also: → 1874675

Note for qe: We should verify that applying wallpaper works as intended and changing between normal and private mode doesn't cause an ANR (or doesn't hang (ignores user input) on low end devices).

Flags: qe-verify+

Verified as fixed on the latest Nightly build (123.0a1 from 2024-01-16).

Devices tested:

  • LG Nexus 5 (Android 6.0.1);
  • Huawei P9 Lite (Android 7.0);
  • Xiaomi Redmi 9C NFC (Android 10).

Applying the wallpaper works as intended and changing between normal and private mode doesn't cause an ANR.

One observation I can add regarding the Redmi device is that on return to normal mode always displays a white screen for a noticeable time before the wallpaper is loaded. With the same device, on RC 122.0, the same issue but with black screen for that moment. I believe however this issue is covered here. The other low end devices performed the transition slowly but no issues were encountered.

Marking the ticket as verified.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Attached image ANR-trends-down.png

I've been monitoring the impact of this patch on different channels. Sharing a screenshot of ANR events (% of unique users who experienced an ANR) trending down from 0.19% before v123 to 0.14% in v123.

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

Attachment

General

Created:
Updated:
Size: