Closed Bug 1511901 Opened 5 years ago Closed 5 years ago

Touchpad two-finger scrolling not working on some sites

Categories

(Core :: Panning and Zooming, defect, P2)

71 Branch
Unspecified
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla70
Tracking Status
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox70 --- verified
firefox71 --- verified

People

(Reporter: federico.targetti, Assigned: botond)

References

Details

Attachments

(10 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

Wanted to use the touchpad two-finger gesture to scroll web pages.

Acer TravelMate P645-S
Windows 10 64bit (Version 1709)
Firefox 63.0.3 64bit
Synaptics driver 19.1.3.9


Actual results:

On some sites like gmail, bugzilla or the Firefox Options, the two-finger scrolling gesture doesn't work and, instead, a shrinking square appears.





Expected results:

Touchpad scrolling should work.
In about:support I see Asynchronous Pan/Zoom: wheel input enabled; touch input enabled; scrollbar drag enabled; keyboard enabled; autoscroll enabled

1. Setting dom.w3c_touch_events.enabled to 0 doesn't solve the issue
2. Setting layers.async-pan-zoom.enabled to false two-finger scrolling partially works (it is very unresponsive)
3. Setting browser.tabs.remote.autostart to false is the better fix that I found for now, but sometimes the scrolling is unresponsive and/or generate zoom events.
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0 
Build ID: 20181206214149            
I manage to reproduce this on Windows 10 x64 with Firefox Nightly 65.0a1 (2018-12-06) (64-bit).
Status: UNCONFIRMED → NEW
Component: Untriaged → Panning and Zooming
Ever confirmed: true
OS: Unspecified → Windows
Product: Firefox → Core
I can try to reproduce on Monday on my Surface Pro. ni on me so I don't forget.
Flags: needinfo?(kats)
I'm not able to reproduce this problem on my Surface Pro with Firefox 63.0.3 and Windows build 1809.

It might just be that the hardware/drivers are sending us unexpected events in this case. The shrinking square thing usually shows up when I do a long-press via touch. I don't think I've seen it any other time.

(In reply to Daniel_A[:daschilean] from comment #2)
> User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0)
> Gecko/20100101 Firefox/65.0 
> Build ID: 20181206214149            
> I manage to reproduce this on Windows 10 x64 with Firefox Nightly 65.0a1
> (2018-12-06) (64-bit).

What device and URL did you see this on? Are there any other steps not listed in comment 0 that might be important here?
Flags: needinfo?(kats) → needinfo?(daniel.aschilean)
Hi Kartikaya,

I reproduced this on Windows 10 Pro 64-bit Build 17134 with Surface Pro 4. I just used the steps from Comment0( you can also try on gmail ).
Flags: needinfo?(daniel.aschilean)
I'm still not able to reproduce. Next step is probably to make a build which logs input events and have somebody who can repro run it.

Sorry for the delay here. Are you still able to reproduce this on a recent Nightly? If so I'll make a build with logging for you to try.

Flags: needinfo?(federico.targetti)

Still able to reproduce on Nightly 67.0a1 (2019-01-30) (64-bit).

Flags: needinfo?(federico.targetti)
Flags: needinfo?(kats)

Ok, here is a build with extra logging:

https://queue.taskcluster.net/v1/task/BVEM9pmFQKuTIHNvqO__IA/runs/0/artifacts/public/build/target.zip

Unzip that and run the firefox.exe, and then reproduce the scrolling problem. Once you reproduce it, shut down the browser. There should be a couple of files created called "bug1511901.txt" and "bug1511901.txt.child-1" (and maybe a few more similarly named ones). Put those in a zipfile and attach it to this bug.

Hopefully the logging will give us some place to start looking. Might need to add more logging to narrow it down based on the first set of logs.

Flags: needinfo?(kats) → needinfo?(federico.targetti)
Attached file bug1511901-log.zip

Here the requested log.

Flags: needinfo?(federico.targetti)

The log shows a lot of touch events and no wheel events. So the trackpad appears to be sending touch events although from the log it's not really clear that the touch sequences are sane. I'll make another build with more detailed logging.

So I don't forget - probably won't get to it until Monday.

Flags: needinfo?(kats)

After some more code archaeology it turns out this is basically bug 1355162 which I filed a while back and I guess I never got around to fixing.

Depends on: 1355162
Flags: needinfo?(kats)
Version: 63 Branch → 68 Branch

There is any chance this bug will ever get fixed ?
It is still present in v68.0a1 (2019-05-10) Nightly.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #13)

After some more code archaeology it turns out this is basically bug 1355162 which I filed a while back and I guess I never got around to fixing.

The description of bug 1355162 says:

Because we are
getting WM_TOUCH events, we go into the APZ pinch-pan code which is not
really ideal for this behaviour.

While not ideal, that codepath should still allow us to scroll. Here, though, it sounds like we can't scroll at all. Does that suggest there may be something else / additional going on here?

The v68.0 update removed support for the browser.tabs.remote.autostart workaround and the bug is still present in the v70.0a1 (2019-07-12) Nightly.
Any suggestion on what to do now ? Am I forced to switch to another browser ?

Version: 68 Branch → 70 Branch

You can try setting dom.w3c_touch_events.enabled to 0 to see if that helps.

Unfortunately it doesn't help also in v68.0 (see comment 1)

(In reply to federico.targetti from comment #16)

The v68.0 update removed support for the browser.tabs.remote.autostart workaround and the bug is still present in the v70.0a1 (2019-07-12) Nightly.
Any suggestion on what to do now ? Am I forced to switch to another browser ?

There are a couple of workarounds you could employ for the time being to force single-process mode (which is what browser.tabs.remote.autostart does):

  • You could use the Extended Support (ESR) version of Firefox, which still supports browser.tabs.remote.autostart.
  • In the regular release version, you can define an environment variable named MOZ_FORCE_DISABLE_E10S. (If you do this, please write yourself a reminder to delete this environment variable once the bug is fixed! You don't want to be using single-process mode any longer than is necessary.)

However, both of these are temporary workarounds: ESR will soon transition to be based on Firefox 68, and the environment variable won't be supported forever either.

For a permanent solution, we need to track down and fix the underlying bug here.

I'll try to take over the investigation here, as Kats is on leave for a while.

I'm still confused about comment 15, but I guess we can keep iterating by creating and testing builds with more logging, and hopefully the issues will become clear.

Assignee: nobody → botond

(In reply to Kartikaya Gupta (email:kats@mozilla.com) (away until Feb-2020) from comment #9)

Ok, here is a build with extra logging:

https://queue.taskcluster.net/v1/task/BVEM9pmFQKuTIHNvqO__IA/runs/0/artifacts/public/build/target.zip

As a starting point, I dug up the logging patch that was included in this build:

https://hg.mozilla.org/try/rev/631be83cf5ea9ee04186eb08000bd89532810fcf

I'll rebase it, add some more logging, and prepare another build to test.

I'll be happy to test it.

Here the requested logs.

(In reply to federico.targetti from comment #24)

Created attachment 9081151 [details]
bug1511901-log.20190728.zip

Here the requested logs.

And, just to double check, during the period while these logs were taken, no scrolling occurred at all? Or scrolling occurred but it was slow / janky?

Could you also mention which page you were trying to scroll?

(In reply to Botond Ballo [:botond] from comment #15)

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #13)

After some more code archaeology it turns out this is basically bug 1355162 which I filed a while back and I guess I never got around to fixing.

The description of bug 1355162 says:

Because we are
getting WM_TOUCH events, we go into the APZ pinch-pan code which is not
really ideal for this behaviour.

While not ideal, that codepath should still allow us to scroll. Here, though, it sounds like we can't scroll at all. Does that suggest there may be something else / additional going on here?

I think I understand now: the pinch-pan codepath only allows us to scroll the root scrollable element on a page, because pinch gesture events are routed to that. Scrolling other scrollable elements won't work with it.

This is consistent with the bug description:

(In reply to federico.targetti from comment #0)

On some sites like gmail, bugzilla or the Firefox Options, the two-finger
scrolling gesture doesn't work and, instead, a shrinking square appears.

These are all pages where the element that's scrolling is not the root scrollable element of the page.

So, Kats' analysis that this requires fixing bug 1355162 is correct.

I produced a new series of logs from pages that partially work (about:config, amazon.com) and pages that do not work at all (Firefox Options menu, bugzilla.mozilla.org).
On pages that partially work, I see almost always a shrinking square, but the two finger gesture scroll the page, albeit not smoothly; on pages that do not work, I see only the shrinking square and no scroll happens.

Thanks -- could you give this build a try please? (Comes from this push.)

This one includes not only logging, but also an attempt at a fix. Please let me know if this allows you to scroll on pages where you previously couldn't. (I'm still interested in the logs as well.)

Here attached a new set of logs for the same sites as comment 28.
Now the touchpad works in some way on all sites, but it always generates the "shrinking square" and it seems that Firefox miss some events. Moreover, the gesture of the two fingers is reversed upside down with respect to the use of the environment variable MOZ_FORCE_DISABLE_E10S.
I tried again to set layer.async-pan-zoom.enabled to false, but the scrolling is bumpy.

(In reply to federico.targetti from comment #30)

it always generates the "shrinking square"

Curious. I'm not exactly sure what this "shrinking square" is, but I assumed it was an OS effect triggered by this NotifyPinchGesture() call.

However, we only make that call if we get into the PINCHING state, and the logs confirm that with the latest patch, we never get into the PINCHING state (which is good). So, it must be triggered by something else.

Any chance you could take a screenshot or photograph of this "shrinking square" and attach it here?

Attached file ShrinkingSquare.zip

Here the "shrinking square". Let me know if you need more info.

Thanks. I see the shrinking square as well on a Windows touchscreen laptop. For me it seems to appear when the second finger goes down on the touchscreen.

I'm not sure what produces it. It's possible it's the OS, without Firefox's involvement. Do you ever see it in other applications besides Firefox?

Anyways, I think we can spin off the issue of the shrinking square to a follow-up bug, and proceed with a fix here even if it's not perfect. (I assume the shrinking square is more of a minor visual annoyance, than a significant usability problem.)

So, let's please try one more build (from this push), hopefully the last one to collect logs from. This one should have the "direction reversed" problem fixed, and it has a bit of extra logging, to log the model and version number of the touchpad (this is necessary because we need to make the change specific to the affected types of touchpads).

Here the logs.
I didn't tested too much the patch (these weeks I have limited access to the internet), but it seems to work now. Thank you.
As per the 'shrinking square', no, I never saw it in other applications besides Firefox.

Thanks. The device identifiers from the log match those in bug 1355162 comment 1. I will prepare an updated patch that employs the fix I wrote for this device type, and post it for review.

By the way -- do you experience this problem in Chrome?

sorry for the review delay, looking at this today.

(In reply to Botond Ballo [:botond] from comment #36)

By the way -- do you experience this problem in Chrome?

No. No problems with Chrome, Edge or IE.

Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/65043aecbd3e
Convert touch events representing two-finger scrolling to pan gesture events for affected devices. r=jmathies
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

Federico, how is the behaviour in the latest Firefox Nightly?

(In reply to Botond Ballo [:botond] from comment #42)

Federico, how is the behaviour in the latest Firefox Nightly?

I've updateted to Nightly 70.0a1 (2019-08-27), but it does not work (no scroll on affected pages, like bugzilla).
Can I activate some log or do anything to help you to solve the issue ?

Interesting. I wonder if I made a mistake in checking the device identifiers. I will prepare a logging patch to shed light on the issue.

Could you try this build please? (Built from this push.)

Also this build does not work.
Here the logs.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Thanks. Based on the logs, the problem is with the device name comparison. We query the length of the device name, and Windows is returning twice the length, even though I'm using the narrow-character version of the API. We then resize the buffer to that length, and comparison with the expected device name fails due to the greater length. Fix coming up.

Ok, the issue should be fixed in this build. (Built from this push.) Could you give it a try?

It works !
Here the logs.

Version: 70 Branch → 71 Branch
Flags: qe-verify+
Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/427273080257
Fix device name comparison in TouchDeviceNeedsPanGestureConversion(). r=cmartin
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED

Federico, could you give today's Firefox Nightly a try please?

It works now.
Many Thanks.

That's great to hear, thanks for confirming!

No longer depends on: 1355162

Comment on attachment 9091198 [details]
Bug 1511901 - Fix device name comparison in TouchDeviceNeedsPanGestureConversion(). r=jmathies

Beta/Release Uplift Approval Request

  • User impact if declined: On devices running Windows with certain touchpad models (affected devices include several Acer Aspire and Acer TravelMate models), two-finger scrolling does not work at all on some websites, including some widely used websites like Gmail.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is a small addendum to the main part of the fix which landed in 70, which fixes a bug in the code to identify the affected devies.
  • String changes made/needed:
Attachment #9091198 - Flags: approval-mozilla-beta?

Comment on attachment 9091198 [details]
Bug 1511901 - Fix device name comparison in TouchDeviceNeedsPanGestureConversion(). r=jmathies

Followup fix for edge cases. OK for uplift for beta 13.

Attachment #9091198 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Hi, I tried to Verify the issue but I was unable to reproduce it in the first place, I tried with an Acer Laptop as well as a Surface Pro 4, on Gmail and Options and other pages but without any success, I was able to scroll using the 2 finger method from Nightly 64 until our latest build.

Federico can you please take a look in our latest Nightly and Beta versions and see if the issue still occurs on your end ? it will help us out a lot. Thank you

You can find the builds here :
NIGHTLY - https://nightly.mozilla.org/
BETA - https://www.mozilla.org/ro/firefox/channel/desktop/

Flags: needinfo?(federico.targetti)

Rares, the issue only occurs on some laptop models (ones that come with a certain model of touchpad, I guess). I wasn't able to reproduce the issue either using my hardware; I based my fix on logging provided by Federico.

Federico did already confirm that a nightly version that includes this patch fixes the problem (comment 54), and a previous nightly that does not include the patch is still affected (comment 43).

Flags: needinfo?(federico.targetti)

Thank you Botond for the updates, I will change the Nightly flag into Verified based on comment 54, but we would still like the reporter to check on Beta on his end since we can't reproduce this issue ourselves.

Federico can you please take a look on Beta as well and confirm that the issue does not occur on your laptop?

BETA - https://www.mozilla.org/ro/firefox/channel/desktop/

Flags: needinfo?(federico.targetti)

Both Nightly 71.0a1 (2019-10-09) and Beta 70.0b13 work for me.

Flags: needinfo?(federico.targetti)

Thanks a lot for Confirming this issue as Fixed, I will mark this issue accordingly based on Comment 63.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Regressions: 1626318

It appears the two-finger scrolling error has resurfaced in an updated Synaptics driver. Running a similar PC as the one in the original comment:

Acer TravelMate P645-SG
Windows 10 Pro 64bit (Version 2004)
Firefox 82.0.2 64bit
Synaptics driver 19.5.45.6

__

Scrolling errors not present in Chrome, Edge or other Windows apps, only Firefox.

(In reply to Derrick H. from comment #65)

It appears the two-finger scrolling error has resurfaced in an updated Synaptics driver. Running a similar PC as the one in the original comment:

Acer TravelMate P645-SG
Windows 10 Pro 64bit (Version 2004)
Firefox 82.0.2 64bit
Synaptics driver 19.5.45.6

__

Scrolling errors not present in Chrome, Edge or other Windows apps, only Firefox.

Thanks for reporting this. Could I ask you to file it as a new ticket, please? I will take a look. (Hopefully it should just be a matter of extending the check to another set of device identifiers.)

Flags: needinfo?(89be9de4-fc5e-43a6-b7b8-1057d4a745ea)

(In reply to Botond Ballo [:botond] from comment #66)

(In reply to Derrick H. from comment #65)

It appears the two-finger scrolling error has resurfaced in an updated Synaptics driver. Running a similar PC as the one in the original comment:

Acer TravelMate P645-SG
Windows 10 Pro 64bit (Version 2004)
Firefox 82.0.2 64bit
Synaptics driver 19.5.45.6

__

Scrolling errors not present in Chrome, Edge or other Windows apps, only Firefox.

Thanks for reporting this. Could I ask you to file it as a new ticket, please? I will take a look. (Hopefully it should just be a matter of extending the check to another set of device identifiers.)

No problem, will do. Thank you for your dedicated work!

Much appreciated.

Flags: needinfo?(89be9de4-fc5e-43a6-b7b8-1057d4a745ea)
See Also: → 1687636
Regressions: 1687636

I think this issue reappeard (ACER P645) after i updated to Win 11. Found a workaround, but this thread was first thing to show up on google while searching. So here is the workaround, hope it helps somebody.

In Synaptics touch pad settings, in the detail view disable ZoomPerfect function https://imgur.com/a/1cSzH2E (screen is in czech but should help to find it)

Maybe this just needs a small update for Win 11?

Flags: needinfo?(botond)

It's not clear what would have changed between Win10 and Win11, but I've rebased the logging patch from earlier in this bug so we can see what the logs show for an affected user on Win11.

Flags: needinfo?(botond)

Ok, here is a build with logging enabled (from this Try push).

If someone who experiences this issue on Windows 11 could download that and get logs following these instructions:

Unzip that and run the firefox.exe, and then reproduce the scrolling problem. Once you reproduce it, shut down the browser. There should be a couple of files created called "bug1511901.txt" and "bug1511901.txt.child-1" (and maybe a few more similarly named ones). Put those in a zipfile and attach it to this bug.

that would be great.

(In reply to hlava.vit from comment #68)

I think this issue reappeard (ACER P645) after i updated to Win 11. Found a workaround, but this thread was first thing to show up on google while searching. So here is the workaround, hope it helps somebody.

In Synaptics touch pad settings, in the detail view disable ZoomPerfect function https://imgur.com/a/1cSzH2E (screen is in czech but should help to find it)

I've got a similar issue after formatting the hard drive and installing again Win 10 (not 11) in an Acer Travelmate P648: I could scroll but it behaved very badly and the "shrinking square" also appeared. I used this workaround and now it works fine. Thanks guys.

You need to log in before you can comment on or make changes to this bug.