(In reply to Razvan Cojocaru from comment #10) > Later debugging report: turns out that calling `SetDefaultAllowedTouchBehavior(apzc, touchBlock);`, like the `ResumeInterruptedTouchDrag_Bug1592435` test does helps keeping `apz.touch_start_tolerance` from being reset to `0.1`. Good find! The behaviour here is not very obvious, unfortunately. What's happening is: * When input events are sent to the APZC (e.g. via TouchMove()), they are not handled immediately, but they go into a queue, and may need to wait for certain conditions to become de-queued and processed. * For touch events, one of these conditions is knowing what the allowed touch-behaviours are for the event. * Normally, the allowed touch-behaviours are computed based on the hit test result, but in some cases they need to be provided externally. (In production, this happens via an IPC message to APZ from the browser's main thread.) * `APZCBasicTester` bypasses hit-testing, so in tests using this harness they always need to be provided externally, by calling `SetAllowedTouchBehavior()`.. * In some test cases (for example `APZCBasicTester.Fling`), this happens inside helper functions such as [Pan()](https://searchfox.org/mozilla-central/rev/fa81b64fc1a339e2b2b1f6a8637a689916e13c4e/gfx/layers/apz/test/gtest/APZTestCommon.h#646-655). * If the touch-behaviors are not provided, the events stay in the queue until the end of the test. At this point, the destructor of the `SCOPED_GFX_PREF_FLOAT` runs and restores the pref to its default value. * The reason the events are subsequently handled is that `Teardown()` runs [delayed tasks](https://searchfox.org/mozilla-central/rev/fa81b64fc1a339e2b2b1f6a8637a689916e13c4e/gfx/layers/apz/test/gtest/APZCBasicTester.h#52), and one of the delayed tasks is a timeout task meant to handle cases where the main thread is too slow to provide information (such as sending that IPC message) and APZ should go ahead and handle waiting events using the information it has. At this point, the events that were waiting are de-queued and processed.
Bug 1755044 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Razvan Cojocaru from comment #10) > Later debugging report: turns out that calling `SetDefaultAllowedTouchBehavior(apzc, touchBlock);`, like the `ResumeInterruptedTouchDrag_Bug1592435` test does helps keeping `apz.touch_start_tolerance` from being reset to `0.1`. Good find! The behaviour here is not very obvious, unfortunately. What's happening is: * When input events are sent to the APZC (e.g. via TouchMove()), they are not handled immediately, but they go into a queue, and may need to wait for certain conditions to be de-queued and processed. * For touch events, one of these conditions is knowing what the allowed touch-behaviours are for the event. * Normally, the allowed touch-behaviours are computed based on the hit test result, but in some cases they need to be provided externally. (In production, this happens via an IPC message to APZ from the browser's main thread.) * `APZCBasicTester` bypasses hit-testing, so in tests using this harness they always need to be provided externally, by calling `SetAllowedTouchBehavior()`.. * In some test cases (for example `APZCBasicTester.Fling`), this happens inside helper functions such as [Pan()](https://searchfox.org/mozilla-central/rev/fa81b64fc1a339e2b2b1f6a8637a689916e13c4e/gfx/layers/apz/test/gtest/APZTestCommon.h#646-655). * If the touch-behaviors are not provided, the events stay in the queue until the end of the test. At this point, the destructor of the `SCOPED_GFX_PREF_FLOAT` runs and restores the pref to its default value. * The reason the events are subsequently handled is that `Teardown()` runs [delayed tasks](https://searchfox.org/mozilla-central/rev/fa81b64fc1a339e2b2b1f6a8637a689916e13c4e/gfx/layers/apz/test/gtest/APZCBasicTester.h#52), and one of the delayed tasks is a timeout task meant to handle cases where the main thread is too slow to provide information (such as sending that IPC message) and APZ should go ahead and handle waiting events using the information it has. At this point, the events that were waiting are de-queued and processed.