Navid, could you please take a look at the example and verify if this is a bug? Thanks!

pointermove action gets an x,y pair not deltaX,deltaY. That might be the problem. Can you try fixing that? basically pass x+deltaX,y+deltaY instead of what you are doing.

Thanks! I will remember that. But the issue here is not the deltas being incorrect. The callback in gpuBenchmarking.pointerActionSequence is not being called.

I believe the problem is passing negative x, y in the parameters. Right now you are passing -90 for the y in the parameter. That causes it to fail. 

Attaching a minimal test to repro this.

Deleted: test.html 1.1 KB

test.html 1.1 KB View Download

Upon further investigation negative number has nothing to do with that. Instead it is related to the fling gesture most likely. Attached another test which is more reflective of the problem.

Thanks! So do we still consider this a bug? Or should this bug be marked as Won't Fix?

I'd keep it open. Because I would expect even in the case of fling we should get the callback called.

Would it be possible to change the API so that the scroll gesture is created without the delay? Currently the test is I am adding is quite slow which is not ideal.

Some context:
https://chromium-review.googlesource.com/c/chromium/src/+/590497/48/third_party/WebKit/LayoutTests/fast/scroll-behavior/scroll-customization/scroll-customization-property.html#195

We should probably add a hook to let us turn off fling generation in the recognizer so we can run tests at full speed. 

Below is the relevant discussion from codereview thread. I think we should continue it here now and come up with a solution.

nzolghadr@: 
I prefer not to have that option for turning off fling though. I'm pretty sure this option will not be available in the webdriver version of these APIs and if you start using that here it wouldn't be easy to change this to use webdriver testing API.

bokan@: 
It seems unreasonable to require each scroll to take at least 50ms and that won't scale. Whether or not web driver support for this is currently planned, WPT will eventually have to grapple with how to deal with this since if we were to move all our scrolling layout tests to use WebDriver in this form testing would slow to a crawl. e.g. This test takes ~5 *seconds* to run. Multiply that by the number of tests that will want to scroll. One solution would be to write WPT with a "kScrollCoolDown" constant that browsers can tweak. If we can turn of fling generation we could ratchet that value down.

tdresser@: 
I agree with Navid that we shouldn't add a flag here. We should come up with some way of preventing fling that works in all browsers.

Bad idea: what about relying on the fact that key presses stop fling?
We could just hit the Ctrl key directly after the finger lifts?
Does that work in all browsers?

bokan@: 
That could be flaky (maybe not in this case) since where the scroll stops will be time dependent. In general it would also add potentially unwanted side effects.

I'm not attached to any particular solution but I do think this will come up again at some point. I've noticed WebKit folks are already uneasy about how long WPT take to run.


tdresser@: 
I can imagine a solution of:
Fling.
Key Press.
Reset scroll position.

Which should be non-flaky as long as long as we pick the right key to press.

I thought that setting scrollTop cancelled a fling, but that doesn't appear to be the case at this point.

I agree we should try to do this in a x-browser fashion.

However I am not sold on using "fling+keypress" to signal not causing fling. In particular in test code I prefer if we are more explicit about the intention which this hack is not.

web-driver spec has a notion of "input source state" [1]. I wonder if we can tweak the API to expose additional arguments that can be used to prime this state. 

Here is a strawman API example:
chrome.weddriver.pointerActionSequence([{
        source: 'touch', params: {allowmMomentumScroll: false}
        actions: [
        { name: 'pointerDown', x: startingX, y: startingY },
        { name: 'pointerMove', x: (startingX + deltaX),
        y: (startingY + deltaY)},
        { name: 'pointerUp'}
        ]
      }], resolve);
    });
  }


As for "kScrollCoolDown" constant, I think that is too implementation specific but something like "AllowmMomentumScroll" is more generic. (Alternatively we can have a MaxMomentumScrollDuration that can be set to 0 to disable it. Although I cannot imagine what you would do with different non-zero value so I prefer AllowmMomentumScroll)


[1] https://w3c.github.io/webdriver/webdriver-spec.html#dfn-input-source-state  

allowMomentumScroll sounds good to me.

+1