Closed Bug 1381435 Opened 7 years ago Closed 7 years ago

Touch events sometime don't register on tab bar (Windows 10)

Categories

(Firefox :: Tabbed Browser, defect, P1)

Unspecified
Windows
defect

Tracking

()

VERIFIED FIXED
Firefox 57
Iteration:
57.1 - Aug 15
Tracking Status
firefox56 --- fixed
firefox57 --- verified
firefox58 --- verified

People

(Reporter: phlsa, Assigned: kats)

References

Details

(Whiteboard: [reserve-photon-visual][p1][high-priority][tpi:+])

Attachments

(6 files)

When using Firefox on a touch screen device, the tab strip currently responds very unpredictable. Sometimes touches on a background tab are registered, sometimes they aren't.
The curious thing is that Windows' touch indicator shows that the tap has hit the tab just fine, but it still won't trigger.
This is particularly annoying on smaller touch targets like pinned tabs or the new tab button.

See the video in the attachment for a demonstration.

FWIW, switching the UI density to touch doesn't change this behavior.

Since we are advertising touch-friendlyness in Photon, I suggest that it should be in scope for that.
Note that the tab strip hasn't been modified for Photon Touch Mode, so making it bigger in bug 1363023 _might_ solve your problem.
(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #0)
> See the video in the attachment for a demonstration.

Which video?
Flags: needinfo?(philipp)
Oops, looks like somehow bugzilla didn't upload my attachment...
Here it is: https://drive.google.com/a/mozilla.com/file/d/0B8v1mZs6cI3_RUZIeFVxTlFyZGs/view?usp=sharing

(In reply to Johann Hofmann [:johannh] from comment #1)
> Note that the tab strip hasn't been modified for Photon Touch Mode, so
> making it bigger in bug 1363023 _might_ solve your problem.

I'm not sure it will. Sometimes the touch indicator (that circle that Windows shows) looks like the event has registered right in the middle of the tab, but it still won't trigger. You can see that happen a few times in the video.
Flags: needinfo?(philipp)
I've been seeing this a lot, too.
I've seen it happen a couple of times, too.

We should probably track this in visuals.
Blocks: photon-touch
No longer blocks: photon-ui-refresh
Whiteboard: [photon-visual][triage]
Also, I just noticed that Edge doesn't have this problem, even though their tabs are almost the same size as ours.
Flags: qe-verify+
Priority: -- → P3
QA Contact: brindusa.tot
Whiteboard: [photon-visual][triage] → [reserve-photon-visual]
Whiteboard: [reserve-photon-visual] → [reserve-photon-visual][p1]
Tweaking title -- when it happens the touch actions are completely broken (i.e. nothing at all happens). Seems easy to reproduce with just a few trivial tabs open, so it's not that Firefox is bogged down and sluggish. Either we're not getting the events, or something goes terribly wrong when handling them.

Felipe, I think you know touch and front-end. :) Suggestions on where to start?
Flags: needinfo?(felipc)
Summary: Improve touch responsiveness of tab bar (Windows 10) → Touch events sometime don't register on tab bar (Windows 10)
When the browser is in this situation, can you try doing a tap-and-drag to see if the entire window will start to be dragged from that same location?  (It shouldn't, you should get tab dragging, not window)

I imagine this has something to do with the calculation of the draggable area directed to the OS (in the past this was the "glass" area.. it doesn't look like glass anymore but the same concept applies). This is done by setting "-moz-window-dragging: drag" through CSS. It's possible that the ongoing tab strip changes has made this worse (and also possible that the just-landed rectangular tabs might have fixed it, so it's worth retesting).

For someone willing to build and do some debugging, I suggest dumping the returned value of ClientMarginHitTestPoint [1]. If it's different than HTCLIENT, then this would be happening. It's likely that this is happening through here: [2], so another thing to debug would be the final values of the draggable area defined by CSS, which will can be seen at UpdateWindowDraggingRegion [3]


[1] http://searchfox.org/mozilla-central/rev/39ccebaf1890f8731d534b5eb3818b66d2b25221/widget/windows/nsWindow.cpp#5326
[2] http://searchfox.org/mozilla-central/rev/39ccebaf1890f8731d534b5eb3818b66d2b25221/widget/windows/nsWindow.cpp#6391
[3] http://searchfox.org/mozilla-central/rev/39ccebaf1890f8731d534b5eb3818b66d2b25221/widget/windows/nsWindow.cpp#3126
Flags: needinfo?(felipc)
Although, afaik, nothing that I pointed there would be different for mouse vs. touch interactions. But it's always possible that entering touch mode would change some CSS? I dunno..

Another theory would be if this happens right after a long touch scroll through flicking. (either the content area or a misinterpreted scroll of the tab bar). If we're still scrolling, your input might be interpreted as just adding more momentum to the scroll, until the kinetic scrolling ends.

I suggest having an overflowed tab strip just to be able to see if the tabs are being scrolled by accident when this happens.


(One place to look for this in the code would be nsWindow::OnGesture, although I don't know anymore if we still use the kinetic scrolling from the OS, or if this is entirely done by APZ now. But both could be at fault here too)
(In reply to :Felipe Gomes (needinfo me!) from comment #9)
> (One place to look for this in the code would be nsWindow::OnGesture,
> although I don't know anymore if we still use the kinetic scrolling from the
> OS, or if this is entirely done by APZ now. But both could be at fault here
> too)

Kats probably knows this, and might have other useful input considering they worked on touch on Windows. :-)
Flags: needinfo?(bugmail)
I tried reproing this but was not able to, tab switching seems to work fine for me. I just opened a few empty tabs in my default profile and switched back and forth between them.

For anybody that can repro this - can you confirm that the tab switching works fine with mouse (and pen input, if you have a pen for your device)? Also, can you go to about:support and check what it says under "Asynchronous Pan/Zoom" in the graphics section?

In terms of the code - with APZ enabled, we do not go through nsWindow::OnGesture. Instead the raw touch events are dispatched to APZ, and APZ does the gesture detection to detect a "tap" event, and then dispatches the set of events to simulate a mouse click. It could be that the gesture detection is failing for some reason (maybe timestamps or positions on the events are off). If somebody is willing to run a custom build with logging I can put together such a build to see if we can get to the bottom of this.
Flags: needinfo?(bugmail) → needinfo?(philipp)
Major issue with touch, we need to fix this. --> high-priority
Whiteboard: [reserve-photon-visual][p1] → [reserve-photon-visual][p1][high-priotity]
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11)

> For anybody that can repro this - can you confirm that the tab switching
> works fine with mouse (and pen input, if you have a pen for your device)?
> Also, can you go to about:support and check what it says under "Asynchronous
> Pan/Zoom" in the graphics section?

Tab switching works perfectly fine with mouse and pen input both. Does not work well at all with touch input. Asynchronous Pan/Zoom says "wheel input enabled; touch input enabled; scrollbar drag enabled; keyboard enabled"
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11)
> For anybody that can repro this - can you confirm that the tab switching
> works fine with mouse (and pen input, if you have a pen for your device)?
> Also, can you go to about:support and check what it says under "Asynchronous
> Pan/Zoom" in the graphics section?

Yes, it works without any issues with both the mouse and the pen.
FWIW, the issue isn't just with tab switching, but also with tapping the close buttons on the tabs.
I can't find any regularities in when it happens though. Sometimes it works fine for 5 taps in a row, then it doesn't for the next few.
The browser console doesn't show anything when it's happening.

APZ says: wheel input enabled; touch input enabled; scrollbar drag enabled; keyboard enabled
Flags: needinfo?(philipp)
(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #14)
> (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11)
> > For anybody that can repro this - can you confirm that the tab switching
> > works fine with mouse (and pen input, if you have a pen for your device)?
> > Also, can you go to about:support and check what it says under "Asynchronous
> > Pan/Zoom" in the graphics section?
> 
> Yes, it works without any issues with both the mouse and the pen.
> FWIW, the issue isn't just with tab switching, but also with tapping the
> close buttons on the tabs.
> I can't find any regularities in when it happens though. Sometimes it works
> fine for 5 taps in a row, then it doesn't for the next few.
> The browser console doesn't show anything when it's happening.
> 
> APZ says: wheel input enabled; touch input enabled; scrollbar drag enabled;
> keyboard enabled

Just chiming in, this should be very easy to repro. I think phlsa and I have the same hardware, surface pro 4 with a very high res screen, so that could be a factor. It's basically impossible for me to work with tabs, opening new ones, switching, closing them, on the current nightly. Something is obviously, unacceptably broken.
Adding just one more bit: Thinking back, I don't think that this has ever worked reliable.
So it might not be a regression. Earlier, I had attributed it to the size of the touch target, but with the new touch mode, it is becoming clear that this is a different kind of problem.
Ah, the high res screen might very well be a factor here. Can you try increasing apz.touch_start_tolerance to see if that helps? It might be that the tolerance is so low that we're detecting the taps as tiny drags instead of clicks. The pref value should be getting multiplied by the DPI reported by the widget, but maybe that's being misreported or it's still not enough or something.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #17)
> Ah, the high res screen might very well be a factor here. Can you try
> increasing apz.touch_start_tolerance to see if that helps? It might be that
> the tolerance is so low that we're detecting the taps as tiny drags instead
> of clicks. The pref value should be getting multiplied by the DPI reported
> by the widget, but maybe that's being misreported or it's still not enough
> or something.

Hm, that pref was set to 0.1 for me. I set it to 1 and then to 5, but didn't notice any difference.
I'm not sure about the tiny drags since Windows shows me the touch indicator (white circle) instead of the drag indicator (white line).
Note that the issue also affects using long-press to trigger the context menu. I'm getting the long press feedback (the box) but then the context menu doesn't trigger.
(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #18)
> Hm, that pref was set to 0.1 for me. I set it to 1 and then to 5, but didn't
> notice any difference.
> I'm not sure about the tiny drags since Windows shows me the touch indicator
> (white circle) instead of the drag indicator (white line).
> Note that the issue also affects using long-press to trigger the context
> menu. I'm getting the long press feedback (the box) but then the context
> menu doesn't trigger.

Hmm this smells like a wrong coordinates problem
I don't think it's just a hidpi / coordinates problem (or at least not a simple/obvious one)...

For me, the touch events _do_ work -- sometimes. Probably an average of 50% of the time, but it varies. For example, if I tap to select a random tab at about 1Hz, sometimes it will work a few times in a row, sometimes it will do nothing a few times in a row, and everything in between.

I also put my device into 100% scaling (vs hidpi 200%), and it acts the same way.
Critical for the release as it isn't a great user experience, tracking it for 57
For those who can reproduce this: are you seeing it only on the tab bar? Or does it also happen on the toolbar buttons/web content area/other? One other thing to try is to increase the value of the apz.touch_move_tolerance pref. I'm pretty sure this is going to fix the problem, after tracing through the code a bit more. My theory is that since the tab bar is a XUL scrollbox, it's not async scrollable, so APZ allows touchmove events to be dispatched after the touch move tolerance. However there is JS code that does preventDefault on the touchmove, since the JS implements scrolling. That preventDefault also prevents APZ gesture detection. The touch move tolerance is set to a much smaller value than the touch start tolerance so increasing it to 0.1 should make the tab bar taps behave more similarly to content area taps.

http://searchfox.org/mozilla-central/rev/0f16d437cce97733c6678d29982a6bcad49f817b/gfx/layers/apz/src/InputBlockState.cpp#852
http://searchfox.org/mozilla-central/rev/0f16d437cce97733c6678d29982a6bcad49f817b/toolkit/content/widgets/scrollbox.xml#540
Whiteboard: [reserve-photon-visual][p1][high-priotity] → [reserve-photon-visual][p1][high-priority]
Setting apz.touch_move_tolerance to 1 seems to do the trick for me!
I might be imagining things, but it seems like there is a little bit of a delay in tab switching after this (but it does seem to work reliably).
(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #23)
> Setting apz.touch_move_tolerance to 1 seems to do the trick for me!
> I might be imagining things, but it seems like there is a little bit of a
> delay in tab switching after this (but it does seem to work reliably).

This works for me too, but is not surprising because phlsa and I have identical hardware.
(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #23)
> Setting apz.touch_move_tolerance to 1 seems to do the trick for me!
> I might be imagining things, but it seems like there is a little bit of a
> delay in tab switching after this (but it does seem to work reliably).

This works for me on a Surface Book. Yay!
Priority: P3 → P1
Whiteboard: [reserve-photon-visual][p1][high-priority] → [reserve-photon-visual][p1][high-priority][tpi:+]
Sorry, I meant setting it to 0.1, not 1!
Priority: P1 → P3
Great! So now it's just a matter of tuning that pref to some appropriate value. To describe it a bit more precisely, the pref controls the distance from the initial touch-down within which touchmove events are suppressed, when the content is not async-scrollable.

If we make the value too large, then things like fingerpainting webapps will become less sensitive to small initial movements, because we'll suppress the touchmove events that the app needs to track the finger's position. Only after the finger moves far enough away from the initial touchdown will we start sending touchmove events, at which point the app would be able to update. In the example of the fingerpainting app, this would manifest to the user as the app not responding to the start of a brush stroke and then suddenly drawing a short line to the current position once the finger has moved far enough. The rest of the stroke will remain responsive; it's only the initial bit that is affected.

I don't think we've tuned this pref at all on desktop before; looking at the history the current value seems to have come from B2G/Android. Unless anybody really wants to spend time figuring out the optimal value for this pref, I propose we increase it to the same value we're currently using for touch_start_tolerance, which is 0.1. According to comment 27 that works well and I think is a reasonable value.
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
Priority: P3 → P1
FWIW, I have the Surface Pro 3 and can't seem to reproduce this issue. apz.touch_move_tolerance is set to default (0.03).
It's possible that we're not getting the right DPI on some of these high-DPI devices, and so those are the only devices that are affected. If anybody is running a local build and has a Surface Pro 4 it should be simple to set a breakpoint or printf at http://searchfox.org/mozilla-central/rev/0f16d437cce97733c6678d29982a6bcad49f817b/widget/nsBaseWidget.cpp#922 and see what DPI is being passed to APZ. I'll check on my older Surface Pro as well to have a baseline for comparison.
On my Surface Pro 1 I get a reported DPI of 144.0. The screen resolution is 1920x1080 which given the real screen size of 9.25" x 5.25" (as measured by my tape measure) is actually around 206-208 dpi. So I wouldn't be surprised if the Surface Pro 4 was even farther off in the reported DPI, causing our touch_move_tolerance calculation to be too small.
Comment on attachment 8895493 [details]
Bug 1381435 - Increase the touch_move_tolerance value on desktop, so taps in the tab bar are detected more reliably.

https://reviewboard.mozilla.org/r/166696/#review171842
Attachment #8895493 - Flags: review?(botond) → review+
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d59ab931a261
Increase the touch_move_tolerance value on desktop, so taps in the tab bar are detected more reliably. r=botond
Setting apz.touch_move_tolerance to 1 seems to help me as well on Dell XPS 13 with touch screen support.
Flags: needinfo?(bugmail)
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e8471e20d775
Increase the touch_move_tolerance value on desktop, so taps in the tab bar are detected more reliably. r=botond
Brindusa, can your team please verify this fix once it hits nightly? It would be good to test this across different devices with different DPIs. Thanks!
Flags: needinfo?(brindusa.tot)
https://hg.mozilla.org/mozilla-central/rev/e8471e20d775
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Iteration: --- → 57.1 - Aug 15
We should probably uplift this to 56 as well.
Comment on attachment 8895493 [details]
Bug 1381435 - Increase the touch_move_tolerance value on desktop, so taps in the tab bar are detected more reliably.

Approval Request Comment
[Feature/Bug causing the regression]: touch events, but only on high DPI devices?
[User impact if declined]: tapping in the tab bar to switch tabs doesn't work reliably
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: not yet, needinfo pending on QA
[Needs manual test from QE? If yes, steps to reproduce]: yes, STR in comment 0/comment 3
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: not really
[Why is the change risky/not risky?]: small pref tweak. it might have a small adverse effect on the user experience with touch input on a small subset of web content, but this is probably negligible. see second paragraph of comment 28 for more detail.
[String changes made/needed]: none
Attachment #8895493 - Flags: approval-mozilla-beta?
Unfortunately, we don't have a high DPI device with a touchscreen. 
I tested this issue on touch screen monitor with Windows 8.1 and Surface Pro 2 with Windows 10 Pro Insider Preview with FF Nightly 57.0a1(2017-08-10) and I can't reproduce the issue, I also wasn't able to reproduce this issue on a build without the fix.
Flags: needinfo?(brindusa.tot)
I can't reproduce this issue on the newest Nightly with the Surface Pro 4, which is a high DPI device with touchscreen.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
False alarm. This remains reproducible with Surface Pro 4 with finger input. It is not reproducible on older or current nightlies with stylus input.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
How frequently are you seeing this? Is it on a lot of the taps, or just a few of them? And can you confirm you're using the August 11 Nightly? Also please try going to about:config and increasing the apz.touch_move_tolerance pref from 0.1 to a larger value (maybe different values in the range 0.2 - 0.5) and see if that helps? No restart required when changing this pref. Thanks!
Flags: needinfo?(gwimberly)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #46)
> How frequently are you seeing this? Is it on a lot of the taps, or just a
> few of them? And can you confirm you're using the August 11 Nightly? Also
> please try going to about:config and increasing the apz.touch_move_tolerance
> pref from 0.1 to a larger value (maybe different values in the range 0.2 -
> 0.5) and see if that helps? No restart required when changing this pref.
> Thanks!


Before pref change, every one in three taps on average.

August 10 Nightly. I added the apz.touch_move_tolerance is set to 1. Build in comment 40 doesn't seem to be ready, nor has it updated to August 11 yet.

After changing the pref to 1, it's more responsive, but the issue still exists and I'm reproducing the bug about one of every five taps on average.
Flags: needinfo?(gwimberly)
(In reply to Grover Wimberly IV [:Grover-QA] from comment #47)
> August 10 Nightly. I added the apz.touch_move_tolerance is set to 1. Build
> in comment 40 doesn't seem to be ready, nor has it updated to August 11 yet.

Ok, let's keep this bug closed for now, since the build you tested doesn't actually have the fix yet.

> After changing the pref to 1, it's more responsive, but the issue still
> exists and I'm reproducing the bug about one of every five taps on average.

I'll make a build with extra logging for you to run so we can figure out what's going on here.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
I pushed a try build with logging to https://treeherder.mozilla.org/#/jobs?repo=try&revision=f674732a8ef0a84e01e3483dad26aba4765db924, please download and try this. To get the logging you'll need to run the build in a cygwin shell.
- download and install cygwin (you can do a minimal/default install)
- download the zip file for the build and unzip it. let's say you download to zip to c:\Users\username\Downloads and then right-click and select "Extract here", so the exe ends up at c:\Users\username\Downloads\firefox\firefox.exe
- open the cygwin shell. by default this should open to the user's home directory, so enter the Downloads directory by typing:
  cd Downloads
- run firefox on the default profile, redirecting the output to a file:
  ./firefox/firefox.exe -P default > output.txt
- reproduce the problem. The build will log stuff for every touch event, so try to use the mouse for opening new tabs and other interactions, and only use touch for tapping in the tab bar. That will make it easier for me to isolate the relevant parts of the log
- Once you encounter the problem, close firefox (with mouse, please) and attach the output.txt file in the Downloads folder to the bug.

Thanks!

Sorry for the complicated steps but AFAIK there's no better way to get stdout/stderr logging from a firefox build on windows.
Flags: needinfo?(gwimberly)
It seems that the builds are still broken/busted/not available for Windows. Can you look into this?
Flags: needinfo?(gwimberly) → needinfo?(bugmail)
The Windows 2012 x64 opt build seems to be ok. Here is a direct link to the zip file: https://queue.taskcluster.net/v1/task/Sf4O6QLBTqaZXI2rg4LkIw/runs/0/artifacts/public/build/target.zip
Flags: needinfo?(bugmail) → needinfo?(gwimberly)
On reddit/r/firefox someone is trying to improve the touch experience tinkering with the values - https://www.reddit.com/r/firefox/comments/6tmlcy/improving_firefoxs_touch_experience_on_windows/

and claims that those changes help. Maybe worth taking a look?
Attached file Terminal window data
Unfortunately the site for Cygwin seems to be down today, so I tried with Git Bash. I got the following (attached) when executing the instructions in Comment 49.

Do note that output.txt was created in the correct directory when the terminal commands were executed but it was blank and no logging seems to have taken place.
Flags: needinfo?(gwimberly) → needinfo?(bugmail)
Hm, git bash should work as well. At least, it seems to work for me. Can you check that when you run with -P default, the profile that gets used has e10s and APZ/touch enabled? If it is not enabled that might explain why you got no output. about:support should include "touch input enabled". Also one thing to note is that the "P" in "-P default" is uppercase; from the output you attached it looked like you used lowercase. As long as it doesn't show the profile manager window it shouldn't really matter though.
Flags: needinfo?(bugmail) → needinfo?(gwimberly)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #54)
> Hm, git bash should work as well. At least, it seems to work for me. Can you
> check that when you run with -P default, the profile that gets used has e10s
> and APZ/touch enabled? If it is not enabled that might explain why you got
> no output. about:support should include "touch input enabled". Also one
> thing to note is that the "P" in "-P default" is uppercase; from the output
> you attached it looked like you used lowercase. As long as it doesn't show
> the profile manager window it shouldn't really matter though.

It does show the profile manager window with both -p and -P. Is the pingsender.exe the program that parses the data for the output file? It seems to not agree with the settings on the Surface Pro. I'll need to mess with some OS settings to get it to run.
Flags: needinfo?(gwimberly) → needinfo?(bugmail)
Attached file output.txt
Here is the data. Please NI me if you need more information.
Flags: needinfo?(bugmail)
Attached file output.txt
Updated file that shows the result of one touch event tap to attempt to open a new tab.
Flags: needinfo?(bugmail)
(In reply to Grover Wimberly IV [:Grover-QA] from comment #57)
> Created attachment 8897498 [details]
> output.txt
> 
> Updated file that shows the result of one touch event tap to attempt to open
> a new tab.

So this shows two touch sequences. It's possible that the hardware picked up two when you only did one (I have had that happen a few times in my own testing).

The first touch sequence here looks like a tap that exceeded the touch_move_tolerance threshold, and so got prevent-defaulted. If this is the problematic touch sequence then we probably just need to increase touch_move_tolerance a bit more.

The second touch sequence seems to have generated a tap correctly, as far as I can tell. If this one is the problematic touch sequence the problem is likely somewhere else in the code. It might be that the mouse events that got generated didn't hit the target or something.

I'll make another build with some more logging to narrow this down.
Flags: needinfo?(bugmail)
Can you please repro again with this build: https://queue.taskcluster.net/v1/task/AAb3ntzeSMuQXTyZHOYeAw/runs/0/artifacts/public/build/target.zip ? Same steps as before (run via git bash, collect output). Thanks!
Flags: needinfo?(gwimberly)
Attached file output.txt
Please NI me if more information is needed.
Flags: needinfo?(gwimberly)
This log is weird, it shows the GPU process crashing on startup and getting disabled. And then there's a drag event, no touch sequences whatsoever.
The drag block is presumably from clicking on the close button to close the browser. So in this case no touch events were received by the APZ code at all. I don't know why but it's possible they got lost because the the GPU process was busy resetting.

Can you please get another log with the same build?
Flags: needinfo?(gwimberly)
Attached file output.txt
In this attempt, I could not get a new tab to open whatsoever.
Flags: needinfo?(gwimberly)
For the record, I'm going to try to get a hold of one of these devices and test myself. It'll probably be faster that way. I'll drop by the Toronto office next week.
Kats, do you want to hold off on uplift to beta while we try to reproduce/verify? 

phlsa, can you still reproduce this or did the fix in Nightly work for you?
Flags: needinfo?(philipp)
I would be comfortable uplifting this to beta because even if it doesn't fix the problem entirely it still helps significantly.
Comment on attachment 8895493 [details]
Bug 1381435 - Increase the touch_move_tolerance value on desktop, so taps in the tab bar are detected more reliably.

Mitigation for issues with touch bar, let's uplift for 56 beta 6.
Attachment #8895493 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #64)
> For the record, I'm going to try to get a hold of one of these devices and
> test myself. It'll probably be faster that way. I'll drop by the Toronto
> office next week.

There weren't any in the Toronto office. jlin ran through the inventory tracker and all the Surface Pro 4 devices are in other offices (and there's not that many of them to begin with). I tried on some other devices and wasn't able to repro the problem.
QA Contact: brindusa.tot → ovidiu.boca
Can't reproduce anymore (and finally clearing my NI)
Flags: needinfo?(philipp)
Flags: qe-verify+
QA Contact: ovidiu.boca → gwimberly
Verfied on Surface Pro 4 Windows 10 64bit with Nightly 58.0a1 (2017-10-03) (64-bit).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.