Fix: (ANR) Input Dispatching Timed Out in Split CardBrowser

[pankaj0695]

Purpose / Description

Describe the problem or feature and motivation

In Tablet/Chromebook when enabling split mode in CardBrower from Settings -> Developer Options and going to CardBrowser, and then scrolling through decks or clicking different decks multiple times causes ANR.

Fixes

• Fixes [Split Browser] ANR: Input Dispatching Timed Out in CardBrowser #19737

Approach

How does this change address the problem?

I have created cardSelectionJob in loadNoteEditorFragmentIfFragmented which opens the split editor after 150ms delay so it prevents opening it multiple times when there are various clicks on the decks, so the final one only opens. It also ensures that the previous cardSelectionJob is cancelled before creating a new cardSelectionJob.

How Has This Been Tested?

Have Tablet/Chromebook
Enable split mode in CardBrower from Settings -> Developer Options
Go to Cardbrowser
then scroll to decks and click them, It should remain responsive without blocking UI thread

I have tested on
Device: Medium Tablet
Android version: 13
API Level: 33

Shared Deck I used: 4000 Essential English Words (all books) [en-en]

Checklist

Please, go through these checks before submitting the PR.

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[david-allison]

I don't feel I understand this issue enough. I suspect this is due to documentation on the issue.

What does this mean:

and then scrolling through decks or clicking different decks multiple times causes ANR.

❓ Do you have a more in-depth explanation for why this occurs?

---

• One of the calls to loadNoteEditorFragmentIfFragmented is under a TODO (but I suspect this is benign)

Anki-Android/AnkiDroid/src/main/java/com/ichi2/anki/browser/CardBrowserFragment.kt

Lines 641 to 658 in 8015ed6

	// TODO: Move this to ViewModel and test
	@VisibleForTesting
	fun onTap(id: CardOrNoteId) =
	launchCatchingTask {
	activityViewModel.focusedRow = id
	if (activityViewModel.isInMultiSelectMode) {
	val wasSelected = activityViewModel.selectedRows.contains(id)
	activityViewModel.toggleRowSelection(id.toRowSelection())
	// Load NoteEditor on trailing side if card is selected
	if (wasSelected) {
	activityViewModel.currentCardId = id.toCardId(activityViewModel.cardsOrNotes)
	requireCardBrowserActivity().loadNoteEditorFragmentIfFragmented()
	}
	} else {
	val cardId = activityViewModel.queryDataForCardEdit(id)
	requireCardBrowserActivity().openNoteEditorForCard(cardId)
	}
	}

The others:

• onSelectedCardUpdated
• redrawAfterSearch

don't seem like they would cause a problem [rather: maybe a minor issue, but not an ANR]

Finally, I'm not sure I agree with the 150ms delay. This adds latency to the happy path and doesn't seem to be necessary.

[pankaj0695]

Do you have a more in-depth explanation for why this occurs?

Actually in split mode, rapid scrolling/tapping triggers many selection events that repeatedly call loadNoteEditorFragmentIfFragmented, these back to back operations queue up faster than the UI thread can process, so this blocks input and eventually causes an Input dispatching timed out ANR

One of the calls to loadNoteEditorFragmentIfFragmented is under a TODO (but I suspect this is benign)

This is likely benign, but rapid interactions can increase calls and opens editor many times.

Finally, I'm not sure I agree with the 150ms delay. This adds latency to the happy path and doesn't seem to be necessary.

The 150ms delay is just a debounce, it can be reduced or removed.

[david-allison]

Why does scrolling trigger events?

If this is onTap, then we should look into handing the TODO

[pankaj0695]

Agreed, scrolling shouldn’t trigger onTap, so the TODO is likely the right fix point. I’ll move this tap handling into the ViewModel and debounce editor loads to avoid repeated loadNoteEditorFragmentIfFragmented() calls.

[david-allison]

Please investigate. What's the cause of the problem?