Some touchmoves are not acked in renderer, resulting is a ever-growing queue |
|||||
Issue descriptionNot all touchmoves are acked back from renderer, which results in an ever-growing TouchEventQueue::ack_pending_async_touchmove_ids_ queue! Luckily the queue holds only int-ids, so the memory-hogging effect is not prominent. But in a phone where Chrome is running for a long time, the result could be terrible. I suspect some crack in acking conditions in RenderWidgetInputHandler::HandleInputEvent is causing this. Here is a repro: 1. Patch crrev.com/1857363004 which adds debug dump & enhances the missing acks by disabling touch coalescing. 2. Compile and run chrome on https://output.jsbin.com/dunuve. 3. Turn on touch emulation. 4. Touch-and-drag multiple times, and see the log. Expected: ack_pending_async_touchmove_ids_ should contain only a few recent unique-touch-ids. Actual: ack_pending_async_touchmove_ids_ grows continuously, collecting all un-acked touchmove ids.
,
Apr 6 2016
Repro w/o changing coalescing: yes but it seems very infrequent. Repro w/touch screen: haven't tried yet.
,
Apr 12 2016
Remove unofficial Blink>Memory component.
,
Apr 20 2016
,
Aug 15 2016
,
Mar 15 2017
This bug is about an old code (old touch_event_queue.cc renamed to legacy_touch_event_queue.cc few months ago). Let's not waste time on this. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by tdres...@chromium.org
, Apr 6 2016