BUG REPORT: Windows 11 Laptop Trackpad - "pan" has been wrongly mapped to "zoom", and "shift" mapping to "orbit" has been accidentally blocked

[OceanHydroAU]

I'm a long-time paying Fusion(360) customer, and I occasionally use my LG Gram laptop (instead of my main workstation that has a mouse.)

The laptop is unusable, because there's no way to navigate my work.

Everything else on my laptop works fine always, including Prusa and Simplify 3D (zoom, pan, orbit are all fine).

Fusion just does not.

Pinch zoom works fine (in and out).

Two-finger-drag left (in) and right (out) also zooms - uselessly and for no apparent reason.

Two-finger-drag up (in) and down (out) also zooms again - treble uselessly now and for no apparent reason.

Nothing whatsoever pans.

Nothing whatsoever orbits.

I've systematically and exhaustedly tried every possible combination of 1 and 2 finger movements while:-

a) alone

b) holding one of: left-button, right-button, left-shift, right-shift, left-control, right-control left-alt, right-alt, and the windows key. 

c) every conceivable combination of 2, 3, 4, and 5 of all of those at once (right-side modifiers only) - e.g. left-mouse-button + right-mouse-button + right-alt + right-ctrl + right-shift = 5-at-once, along with one and two finger drag:

besides "shift" sometimes preventing those unwanted zooms, and some mouse clicks causing marking or the marking menu, no combination at all performs any pan or orbit.

My settings are all default as far as I'm aware.  I did try changing the mouse stuff in Fusion, but that didn't fix anything, and broke how my real mouse works on my other machine, so I had to change it back.

Am I doing something wrong?

Do I need some special settings in Windows 11 maybe, to "fool" Fusion so it works?

Should I contact support and ask them? (might help me: won't help anyone else)

Should I report this as a bug? (might help everyone, as well as me)

Has anyone out there on Windows ever seen Fusion working with a trackpad?  Any idea how they got it going??

(Update next day) - I tested this on a different laptop (RoG Strix) - exact same problem.

I am beginning to think this is two bugs:

1) Either shift key, when pressed, blocks the two-finger-drag on the trackpad from doing anything at all.  This is clearly a mistake (ctrl/alt/win don't block it) and it was probably intended that the shift key was supposed to behave like it does with a mouse (permit Orbit navigation).  It does *do* something (blocks the trackpad) but it's just doing the wrong something (should be engaging "orbit" mode).

2) "pan" has been incorrectly mapped to "zoom" - since the two-finger-drag up/down/left/right is producing treble-redundant zoom-in / zoom-out when that's already available with pinch - it seems 99% probable that someone has accidentally mapped what was *supposed* to be "pan" movements, over to "zoom" ones.

Fixing both of those 2 minor issues would make Fusion able to be used on Windows laptops.

@Phil.E - I logged this with support (Case ID: 22427343) and suggested they contact you to have it entered into your work queue; I hope that's OK!

[lance.carocci]

Hi @OceanHydroAU,

Let's cut to the chase: Fusion on Windows currently has no touchpad gesture support. Reassigning gestures at an OS level also does not work - Fusion does its own event interpretation independent of the OS.

This is an undesirable experience and one under active investigation to improve.

If you care how the sausage is made: There is currently an event timing issue preventing Fusion from telling input devices apart - some layer is telling Fusion to Zoom before it can get direct input and see, e.g. 2 finger drag/swipe. A similar issue currently prevents the Apple Magic Mouse from being interpreted as a mouse and not a trackpad on the macOS client.

[OceanHydroAU]

Thanks Lance - I've been wondering about this for a few years now, and before my tests this week, I thought it was just something I'm doing wrong.  I'm a programmer myself, and thinking hard about how and why the "shift blocks zoom" curiosity is going on, it seems almost certain now that the actual problem here is just the pair of trivial mistakes I named in the title of this post.

Fixing those, will simply "make it work right" without any adverse impacts as best I can tell!

My fingers are crossed!

[OceanHydroAU]

Grumble - Fusion support delete my case 22427343 without reading it, and told me to try some key combos which do not work (which my case 22427343 already said I'd tried... sheesh...)

@lance.carocci - are you able to log this bug and get an issue number for it, so we know it's in the Fusion queue to be resolved?  If not - can you find support case 22427343 and re-open it?  (that case includes instructions for how to reach the right Autodesk team to get this bug logged in the system)

[lance.carocci]

---

@OceanHydroAU wrote:

Thanks Lance - I've been wondering about this for a few years now, and before my tests this week, I thought it was just something I'm doing wrong.  I'm a programmer myself, and thinking hard about how and why the "shift blocks zoom" curiosity is going on, it seems almost certain now that the actual problem here is just the pair of trivial mistakes I named in the title of this post.

Fixing those, will simply "make it work right" without any adverse impacts as best I can tell!

My fingers are crossed!

It's more that we are working with some legacy code that made some assumptions about the state of the Windows and Qt input APIs circa 10 years ago - i.e. the Precision Trackpad API didn't really come to fruition until 8.1, which itself was largely ignored. With 10 now - and soon 11 - being the baseline for Windows app support, it's long past time to revisit the input experience.

Grumble - Fusion support delete my case 22427343 without reading it, and told me to try some key combos which do not work (which my case 22427343 already said I'd tried... sheesh...)

@lance.carocci - are you able to log this bug and get an issue number for it, so we know it's in the Fusion queue to be resolved?  If not - can you find support case 22427343 and re-open it?  (that case includes instructions for how to reach the right Autodesk team to get this bug logged in the system)

---

Your case data is confidential and out of my reach - if you wish, you can contact support once more to reopen, but I don't think it's necessary as this issue is already under investigation by the engineering team.

[OceanHydroAU]

---

already under investigation by the engineering team

Awesome - thanks for the update Lance!  I wish that team luck sorting this out.

[OceanHydroAU · Accepted solution]

Good news everyone!  I just got this response to my support request:-

I have escalated this issue to the development team, I would like to inform you that the change request FUS-153307 for this case has been entered into our development system.

Looks like a resolution to this problem is now in the queue!

[OceanHydroAU]

I wish your video people had spoken to you before they made this: https://www.youtube.com/watch?v=XnuanodHy7E

It would have been nicer to make Navigation work properly first!