1299239 - [e10s] Nightly moves at a 2-3 second delay when moving window with stylus on a touch screen

Status: NEW

(Core :: Widget: Win32, defect, P3)

Description

[u554753]

Mozilla/5.0 (Windows NT 10.0; rv 51.0) Gecko/20100101 Firefox/51.0

[Pre-Requisites] 
javascript.options.asyncstack; false
browser.tabs.remote.force-enable; true
browser.tabs.remote.autostart.2; true 
about:support Multiprocess Windows 1/1 (Enabled by user)
layers.async-pan-zoom.enabled; true 
about:support Asynchronous Pan/Zoom wheel input enabled; touch input enabled

[Steps to Reproduce]
1. Navigate to a URL (eg: http://www.whatisblik.com/ )
2. Using your finger hold and press on the Title Bar to drag the windows

[Expected Results]
The window does not move with a noticeable delay.

[Actual Results]
The window moves with a noticeable delay. (Up to 3 seconds behind the user finger input)

[Note]
This only happens when e10s is enabled. When e10s is disabled, the window does not move with a noticeable delay.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

I'm not able to reproduce this one. Can you confirm that on the same page, moving the window using the mouse has no lag? i.e. only the touch-based dragging is delayed?

Comment 2

[u554753]

I cannot reproduce the issue using a mouse or the touchpad. It does not have a lag.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Ok, thanks.

Comment 4

[Kanchan Kumari QA]

Hello Kartikaya, I observe slight lag with fingers/pen/stylus touch too(maybe around 1 second). Using mouse has no lag.
Tested on:
Surface Pro 4  
i5-6300U CPU 2.40GHz

Comment 5

[Kanchan Kumari QA]

Attachment: TinyTake07-09-2016-02-36-11.mp4

This is more noticeable when resizing the window with stylus.

https://ranisharma22.tinytake.com/sf/OTU3ODU3XzQwMTM1ODA

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Thanks for the video! It looks like maybe we're not coalescing these events as much as we should be, so we're doing lots of wasted intermediate resizes. If that theory is correct it shouldn't be too hard to track down and fix.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

So actually using a stylus resizing the window you are doing in comment 5, I can reproduce this even in 49 release *without* e10s. I don't ever see the lag while moving the window though, on any channel with or without e10s, using stylus or touch.

Still, it's probably worth looking into the stylus resizing lagginess and seeing if there is an opportunity for event coalescing that will help. That might fix the window moving lagginess as well.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

I spent some time looking into the laggy stylus resizing. As far as I can tell, the windows widget code is getting the same sequence of messages (WM_ENTERSIZEMOVE, WM_SIZING*, WM_EXITSIZEMOVE) regardless of whether mouse or stylus is used. Since I can repro this easily with e10s disabled any overhead/asyncness from the IPC or reflow interruption code is not relevant here.

I tried using the Gecko profiler to compare profiles when resizing with mouse vs stylus, and I see that in the stylus case there's a much higher portion of time (~30%) spent in NtUserPeekMessage, but I'm not sure why.

I also tried searching MSDN and online for any clues as to whether mouse events get coalesced by Windows more than stylus events but didn't come up with anything. I tried to build the VisualStudio backend so that I might be able to use perf tools in VS to figure out what was going on but after spending over an hour loading the .sln file VS crashed so I don't want to spend any more time on that approach.

I'm still unable to reproduce any lag when *moving* the window, only when resizing it with stylus. Not sure what to do here, but I'm fairly confident the fix will be in the windows widget code somewhere.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Is the version field on this correct? Also, is this really a regression based on comment 7?

Comment 10

[Kartikaya Gupta (email:[e-mail])]

There are two issues identified in this bug - (1) is that moving the window with touch is laggy, and (2) is that resizing the window with touch/stylus is laggy. The bug was initially filed about (1) which I cannot reproduce. My comments are about (2) which I can reproduce. (2) doesn't seem to be a regression, but (1) might be. In that case it would be a regression in 52 with touch support enabled.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

The video in comment 5 is pretty ugly. Is Windows e10s touch support still riding the 52 train? If so, anything we can do to help move this bug along?

Comment 12

[Jim Mathies [:jimm]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #11)
> The video in comment 5 is pretty ugly. Is Windows e10s touch support still
> riding the 52 train? If so, anything we can do to help move this bug along?

We've really never given stylus support priority but maybe it's time to revisit this.

Comment 13

[Andrew Overholt [:overholt]]

FWIW I can reproduce the laggy window resizing with the stylus on a Surface Book.

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Jim Mathies [:jimm] from comment #12)
> ...
> We've really never given stylus support priority but maybe it's time to
> revisit this.

Other applications work well, and it seems it's just a question of events getting queued up and processed one by one instead of getting coalesced - Jim, any thought as to who'd be a good person to look at this?

Comment 15

[Jim Mathies [:jimm]]

Yes we need to work on this at some point, but currently not a priority.

Comment 16

[Andrew Overholt [:overholt]]

Given comment 15 and a similar comment from Jim offline I'm marking this fix-optional.