Skip to content

Fix non-passive touch event listeners on EntityCardComponent - #4762

Open
narayandesai wants to merge 1 commit into
Kareadita:developfrom
narayandesai:bugfix/touch-event-listeners
Open

Fix non-passive touch event listeners on EntityCardComponent#4762
narayandesai wants to merge 1 commit into
Kareadita:developfrom
narayandesai:bugfix/touch-event-listeners

Conversation

@narayandesai

Copy link
Copy Markdown

Fixes scroll-blocking violations caused by non-passive touch event listeners on entity cards with large series (100+ issues).

Angular's @HostListener has no mechanism to register passive event listeners. This replaces touchmove and touchstart handlers with manual addEventListener calls using { passive: true }, properly wired up in ngOnInit and cleaned up via destroyRef.onDestroy().

The touchend listener remains non-passive since its handler calls preventDefault() to suppress tap-after-long-press navigation.

Angular's @HostListener has no mechanism to register passive event
listeners. With large series (100+ issues), each rendered entity card
was registering non-passive touchmove and touchstart listeners, causing
the browser to block scrolling on every touch event and triggering
repeated '[Violation] Added non-passive event listener to a
scroll-blocking event' warnings in the console.

Fix: replace both @HostListener('touchmove') and @HostListener('touchstart')
with manual addEventListener calls using { passive: true }, wired up in
ngOnInit and cleaned up via destroyRef.onDestroy(). Neither handler calls
preventDefault(), so marking them passive is safe.

@HostListener('touchend') is left as-is because its handler does call
event.preventDefault() to suppress tap-after-long-press navigation,
which requires the listener to remain non-passive.
@narayandesai

Copy link
Copy Markdown
Author

This patch improves performance, particularly on series with many chapters.

@majora2007

Copy link
Copy Markdown
Member

Utilizing Renderer2 to register for passive events would be best, rather than directly registering.

What size of library were you able to reproduce with? I haven't seen any scroll jank on my 1.2K library with my tablet.

@narayandesai

Copy link
Copy Markdown
Author

I was seeing extremely long series view load times for a series with hundreds of issues. (like 10s of seconds? maybe more?)

I tried using Renderer2 this morning, but was unable to figure out how to pass { passive: true }. While this was better than the initial version, it still took 6-10s for the initial structure render and longer to get thumbnails visible. The non-angular version of the patch had subsecond loading. lmk what direction you'd like me to go with this.

@majora2007

Copy link
Copy Markdown
Member

Are you sure the load time was not just the backend preparing and sending the request?

The series detail does some work in memory for sorting into groups. It definitely can be heavier for series with large amounts of chapters/volumes.

Would be helpful to attach network tab and do some further investigation.

@narayandesai

narayandesai commented Jun 22, 2026

Copy link
Copy Markdown
Author

series-detail takes just short of a second (981 ms), but there is a large gap (~10s) in the network display where no requests are active. This looks like a client side issue to me.

@github-project-automation github-project-automation Bot moved this to In progress in Kavita Aug 12, 2026
@github-project-automation github-project-automation Bot moved this to In progress in Backlog Aug 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In progress
Status: In progress

Development

Successfully merging this pull request may close these issues.

2 participants