DragPage gesture does not work when the physical mouse pointer is outside the window. |
||||||||||
Issue descriptionWhen using DragPage gesture repeatedly, the results are not reproducible. It depends on the location of the physical mouse pointer. If the mouse pointer is within the chrome window that is recording / running the benchmark then it works well. If the mouse pointer is outside the chrome window, the first DragPage event works fine and then it appears as if the page jumps to a random location (which I guess depends on the position of the mouse) and then performs the second drag action. What steps will reproduce the problem? (1) Apply this patch: https://codereview.chromium.org/2799663002/ (2) Try to record a wpr using this command: ./tools/perf/record_wpr v8_runtime_stats_desktop_browsing_benchmark --story-filter=earth (3) Leave the physical mouse pointer somewhere outside the browser window that is recording the wpr. What is the expected result? The page should have a smooth scroll. What happens instead? Depending on the mouse location we can see a jump after the first scroll.
,
Oct 12 2017
,
Oct 12 2017
Over to Dave to delegate.
,
Oct 12 2017
This is likely an interaction between the physical device actually generating events and what you are recording. Seems to me that chrome really should support a mode where input is not allowed from physical hardware and is discarded. Would adding this to content_shell help in this case?
,
Nov 10 2017
I am not sure it is related but there is RepeatableBrowserDrivenScroll (https://cs.chromium.org/chromium/src/third_party/catapult/telemetry/telemetry/internal/actions/action_runner.py?q=RepeatableBrows&sq=package:chromium&l=444) for repeatedly scrolling page does not have this problem. Does it help if we do something similar for Drag page?
,
May 2 2018
+Ned, any thoughts on Dave's proposal in #4? This seems reasonable to me.
,
May 2 2018
I like Dave's proposal in #4 a lot. I think we may couple this with the '--enable-automation" flag in Chrome +Pavel: the context is we want to disable input from physical hardware when we are running browser in the automated test mode
,
Aug 22
Ping on this bug. Are we going with the approach mention in comment #4. Any timeline on when we would have this feature? We need this feature to record google maps pages properly on Mac and Windows. More context in this bug crbug.com/773084.
,
Aug 22
Over to Navid. I'm not working on input these days so Navid can priortize resources to do this.
,
Aug 24
Navid, just for context, this is causing us to disable some v8 / system health benchmarking stories that use DragPage. Any idea when this might be able to be fixed?
,
Aug 24
A few questions here. Since by dragging you expect the scrolling to happen I suspect you are injecting the touch input. correct? If so I believe there might be a fling going on after the release of the touch (i.e. end of drag) which changes the scrolling. You might need to tap somewhere or something like that to stop the ongoing fling in the test.
,
Aug 30
I am sorry for the delay. We don't want to actually inject a touch input. From what I checked last, on Mac touch events are not supported. The RepeatableBrowserDrivenScroll generates the mouse wheel events on Mac. The mouse wheel events are used to zoom in and out on the Google maps pages. Instead of zooming when we actually want to move the maps to a different location (kind of scrolling) we have to use the drag event on Mac. On Linux, where the RepeatableBrowserDrivenScroll translates to touch events the recording works fine.
,
Jan 16
,
Jan 16
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by skyos...@chromium.org
, Apr 5 2017