Inspiring

P: Completely broken Hand tool (PS24.5) Hand Tool Sticking, sticky, not seeing mouse-up

Forum|Forum|2 years ago
May 31, 2023
538 replies
76649 views

This is a bug. Please don't move it to the Discussions tab.

And please don't merge into another unrelated thread. I will report a bug with this thread.

------------------------------------

I made a YouTube video using a keyboard mouse overlay to show what action I'm taking. I hope you can refer to refer to it.

https://youtu.be/Cle6dEgP5_Y

------------------------------------

I was disappointed that there were so many bugs that were not fixed in 24.5, but I was still trying to give it a shot.

However, this bug is pretty serious. Really...

Please see the video I attached.
If you watch the video, you will see that I am shaking the screen.
I'm not using a hand tool, it should release automatically, but that thing is sticky.

To release this sticky, pinned handtool, you'll need to make one more unconditional click.

Here's how I've organized them for your reference.

< What I can be sure of >

Window10 (Tested a total of 14 PCs)
Use WacomTablet
Not related to preferences at all (Especially not related to Spring loaded, Flick panning stuff things)
I've tried all the known Photoshop troubleshooting methods and no improvement.
Even reinstalling Windows does the same thing
Only in 24.5 does this bug occur with certainty. I can't reproduce it at all in earlier versions.

< I'm not sure about the >

Mac OS not tested
I couldn't even test if it was a GPU company difference. I and my team all use NVIDIA

And while there are a few threads pointing this out, there doesn't seem to be a proper plan to fix it.

If this is not fixed in 24.6, 24.6 will be equally unusable as 24.5.

Also check out the links below.

https://community.adobe.com/t5/photoshop-ecosystem-discussions/hand-tool-lock-after-releasing-spacebar/m-p/13877080/page/3#M739535

https://community.adobe.com/t5/photoshop-ecosystem-bugs/some-ps-tools-keep-reading-wacom-pen-after-lifting-from-tablet/idi-p/13875630

https://community.adobe.com/t5/photoshop-ecosystem-discussions/hand-tool-won-t-let-go-of-image/m-p/13863098

https://community.adobe.com/t5/photoshop-ecosystem-bugs/24-5-impossible-to-use-with-wacom-intuos-on-windows/idi-p/13845137

(cjbutler 1/12/24: edited title from "not reverting to cursor" to "not seeing mouse up" to reflect latest focus on lost mouse-up as root cause, and not just a stale cursor setting.)

2023-06-20_11-02-30.zip

Windows

Show previous replies

alanp6536080

Known Participant

Hi @CJButler

After reading @Vit Kovalcik 's post I've done some investigation using Spy++ on the problem as it affects my own system. (Windows 10, nVidia GTX 1060, Wacom Intuos tablet, PS 25.1.0)

With this I *never* see the issue using a mouse. I *do* see the issue with a Wacom tablet if I have UseSystemStylus=0 in a PSUserConfig.txt file AND have Use Windows Ink set to OFF; I do *not* see the issue with a Wacom tablet with no PsUserConfig.txt and Use Windows Ink set to ON.

And *rarely* the issue goes away for no apparent reason and I don't see it at all.

The test sequence was the same in all the tests I did. Spy++ was looking at

WM_KEYDOWN

WM_KEYUP

WM_LBUTTONDOWN

WM_LBUTTONUP

WM_MOUSEMOVE

WM_POINTERDOWN

WM_POINTERUP

and set to track all windows in same thread, all windows in same process, child windows and parent windows.

PS was open with a PSD file that I had smaller than the main window to give me a background. All tool windows were closed. The Hand tool was preselected.

The sequence was this:

Move cursor into the PS window, click once on the background to give it focus

Move cursor into the image

Click and hold to pan the image

Lift the mouse button or pen and see what happens

In the "Mouse with Windows Ink OFF" log I used a mouse with UseSystemStylus=0 in PSUserConfig.txt, and the tablet driver set with Windows Ink OFF. I have *never* seen the problem in this configuration and the log looks clean.

In the "Tablet with Windows Ink ON" log I used a Wacom tablet, with no PSUserConfig.txt file, and the tablet driver set with Windows Ink ON. I do *not* see the problem here and the message flow in the log seems sensible.

In the "Tablet with Windows Ink OFF" log I used a Wacom tablet, with UseSystemStylus=0 in PSUserConfig.txt, and the tablet driver set with Windows Ink OFF. This is the only configuration where I see the problem.

Here there is no WM_LBUTTONUP message when I lift the pen, although from then on WM_MOUSEMOVE's wParam does show that no button is pressed.

The major difference is that in the Windows Ink ON case I see

WM_POINTERUP

WM_LBUTTONUP

when I lift the pen, and with Windows Ink OFF I see neither. I've annotated the logs to show sequencing.

In the mouse case, I see a WM_LBUTTONUP as I would expect.

---

So is that any help to you?

As a thought - is there any mileage in you giving a test recipe for those of us able to use Spy++ to get the maximum amount of information out? I was tracking the mesages that seemed most useful from your recent explanation, but is there more that could help?

Alan

---------------------------------------

Mouse With WIndows Ink OFF

======================

SEQUENCE USING MOUSE WHERE PROBLEM DOES NOT OCCUR
-------------------------------------------------

This sequence is generated using a mouse. I have never seen the problem with a mouse
I have UseSystemStylus = 0 in PSUserConfig.txt, and Use Windows Ink is ON.

In this configuration I do see the problem with a tablet.

I move the mouse cursor into the PS window

<000001> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:1038 yPos:427
<000002> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:974 yPos:415

... many repeats

I click and release to give PS focus. I don't see a WM_LBUTTONDOWN?

Here the mouse cursor does not change to the Hand cursor until I move the
mouse.

<000012> 00000000000212CA P WM_LBUTTONUP fwKeys:0000 xPos:870 yPos:378
<000013> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:871 yPos:378

Now I move the nmouse cursor into the image

<000014> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:874 yPos:383

... many repeats

I click and hold the left button

<000051> 00000000000212CA P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:517 yPos:302

I move the mouse around and the image pans as expected. The WM_MOUSEMOVE wParam
shows the left button down as expected.

<000052> 00000000000212CA P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:518 yPos:303

... many repeats

I lift the left button and see a WM_LBUTTONUP

<000066> 00000000000212CA P WM_LBUTTONUP fwKeys:0000 xPos:737 yPos:389

And now mouse moves do not cause panning. The WM_MOUSEMOVE wParam
shows the left button up as expected.

<000067> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:737 yPos:389
<000068> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:736 yPos:389
<000069> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:735 yPos:389

Tablet With WIndows Ink ON

======================

SEQUENCE USING TABLET WHERE PROBLEM DOES NOT OCCUR
--------------------------------------------------

This sequence is performed using a Wacom Intuos tablet.
I have Use Windows Ink turned ON, and there is no PSUserConfig.txt file

I move the cursor into the PS window

<000001> 0000000000031416 P WM_MOUSEMOVE fwKeys:0000 xPos:1225 yPos:440
<000002> 0000000000030FB2 P WM_MOUSEMOVE fwKeys:0000 xPos:9 yPos:411

... many repeats

I tap and release on the PS window background to give it focus. The cursor changes immediately
to the Hand cursor.

Here I am seeing WMPOINTER* messages

I also see a WM_LBUTTONDOWN message

<000074> 0000000000040FBE P WM_POINTERDOWN wPointerID:0002 wFlags:6016 ptX:1378 ptY:597
<000075> 0000000000040FBE P WM_MOUSEMOVE fwKeys:0000 xPos:1151 yPos:425
<000076> 0000000000040FBE P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:1151 yPos:425
<000077> 0000000000040FBE P WM_POINTERUP wPointerID:0002 wFlags:6002 ptX:1378 ptY:596
<000078> 0000000000040FBE P WM_LBUTTONUP fwKeys:0000 xPos:1151 yPos:425

Now I move the cursor into the image

<000079> 0000000000040FBE P WM_MOUSEMOVE fwKeys:0000 xPos:1154 yPos:421

... many repeats

I tap and hold on the image

<000217> 0000000000040FBE P WM_POINTERDOWN wPointerID:0002 wFlags:6016 ptX:884 ptY:600
<000218> 0000000000040FBE P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:657 yPos:428

I pan the image, and WM_MOUSEMOVE wParam shows the left button is down

<000219> 0000000000040FBE P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:677 yPos:436
<000220> 0000000000040FBE P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:681 yPos:438

... many repeats

I lift the pen and see "up" messages

<000259> 0000000000040FBE P WM_POINTERUP wPointerID:0002 wFlags:6002 ptX:1122 ptY:723
<000260> 0000000000040FBE P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:895 yPos:551
<000261> 0000000000040FBE P WM_LBUTTONUP fwKeys:0000 xPos:895 yPos:551

And now the image is not panning, and WM_MOUSEMOVE wParam shows the left button is not down

<000262> 0000000000040FBE P WM_MOUSEMOVE fwKeys:0000 xPos:895 yPos:551
<000263> 0000000000040FBE P WM_MOUSEMOVE fwKeys:0000 xPos:893 yPos:544

Tablet With WIndows Ink OFF

======================

SEQUENCE USING TABLET WHERE PROBLEM DOES OCCUR
----------------------------------------------

This sequence is generated using a Wacom Intuos tablet.
I have UseSystemStylus = 0 in PSUserConfig.txt, and Use Windows Ink is ON.

A major difference between this case and the log where I don't have this is that I don't see
WM_POINTER* messages.

To start I use the Wacom pen to move the cursor into the background of the PS window

<000001> 0000000000080ABA P WM_NCMOUSEMOVE nHittest:HTBOTTOM xPos:1379 yPos:899
<000002> 00000000000214A8 P WM_MOUSEMOVE fwKeys:0000 xPos:778 yPos:15

... many repeats

I tap on the background of the PS window to give it focus, and I get the cursor for the Hand tool

I see a WM_LBUTTONUP, but no WM_LBUTTONDOWN

<000119> 00000000000212CA P WM_LBUTTONUP fwKeys:0000 xPos:903 yPos:429

Now I move the cursor into the image

<000120> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:902 yPos:430

... many repeats

I tap and hold on the image

<000248> 00000000000212CA P WM_LBUTTONDOWN fwKeys:MK_LBUTTON xPos:451 yPos:357

I start to pan the image around. In these messages, WM_MOUSEMOVE's wParam is detecting the
left button down. PS works as expected.

<000249> 00000000000212CA P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:452 yPos:357
<000250> 00000000000212CA P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:453 yPos:357
<000251> 00000000000212CA P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:454 yPos:357
<000252> 00000000000212CA P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:455 yPos:357

... many repeats

At some point in the sequence I lift the pen from the tablet. The image continues to pan even
though I have lifted

I don't see a WM_LBUTTONUP. But WM_MOUSEMOVE's wParam is correctly showing that the left
button is not down.

<000293> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:765 yPos:229
<000294> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:764 yPos:225
<000295> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:766 yPos:225
<000296> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:773 yPos:228
<000297> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:774 yPos:230

Finally I hit the ESCAPE key and the tracker stops the panning action

<000365> 00000000000212CA P WM_KEYDOWN nVirtKey:VK_ESCAPE cRepeat:1 ScanCode:01 fExtended:0 fAltDown:0 fRepeat:0 fUp:0
<000366> 00000000000212CA P WM_CHAR chCharCode:'27' (27) cRepeat:1 ScanCode:01 fExtended:0 fAltDown:0 fRepeat:0 fUp:0
<000367> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:442 yPos:390
<000368> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:442 yPos:390

... many repeats

<000379> 00000000000212CA P WM_KEYUP nVirtKey:VK_ESCAPE cRepeat:1 ScanCode:01 fExtended:0 fAltDown:0 fRepeat:1 fUp:1

From here a pen move is not panning the image. PS is responding correctly to the WM_MOUSEMOVE's wParam being zero.

<000380> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:453 yPos:389
<000381> 00000000000212CA P WM_MOUSEMOVE fwKeys:0000 xPos:453 yPos:388

Vit Kovalcik

Known Participant

@CJButler: You are right! I didn't think it was possible, but I did a test:

I used Spy++ from MS Visual Studio package (the 64-bit version spyxx_amd64.exe to be precise). I tried other apps, so other people could test it too without installing Visual Studio, but so far I failed.

My process:

- Preparation in PS: Open a file, switch to hand tool, from then on use just left mouse button, no keyboard, no tablet (even though I have a Wacom tablet and its drivers)

- Spy++ settings: Watching message from Photoshop and message from the same thread and same process

- Spy++ settings: Watching _only mouse_ messages, otherwise it gets messy very fast

- Spy++: Start the capture, switch to PS

- PS: After a few drag movements, the tool remain stuck and as you wrote WM_LBUTTONUP is indeed missing. But many times few seconds before that, on occasions when the tool was not stuck, the WM_LBUTTONUP was sent, so there is indeed this glitch from time to time.

You can ind the respective log here:

https://www.pastel.cz/temp/ps_messages_error.zip

After message 004166 I ended up with a stuck tool, waited for a while (no new messages occured), Alt-Tabbed to Spy++ and terminated the logging, so no further mesasges are relevant.

I also tried to capture mouse messages from ALL WINDOWS, but WM_LBUTTONUP was again not sent at all.

If there is anything else you would like me to test, I would be happy to try it.

JqqerryAuthor

Inspiring

@CJButler Hi. Thanks for coming this thread.
I press the spacebar very often because I'm a Retoucher, but when I reproduce that bug, I just press it once very slowly and it reproduced.
I don't know how this works (because I'm not a programmer).

https://community.adobe.com/t5/photoshop-ecosystem-discussions/when-press-f-doesnt-change-screen-mode/m-p/13277784

I reported on this last year. I thought it was a bug that wasn't serious, and actually that failed when I tried to change the screen mode myself, so I had to turn off Photoshop and turn it back on unconditionally at the time. But after version 24.5, I often had that bug and I inadvertently pressed the spacebar just one more time (hand tool was not active). And that's solved.
So I changed my mind. I also claimed that by the time I reported this bug earlier, I had considered issues with Windows Ink, Wacom, or user settings, and that Photoshop's own installation file was broken.

But don't think it's working well to return that spacebar from a version at some point (that's more prominent from 24.5). (Nothing to do with spring rod options)

If you press and release the spacebar, you should recognize it.
But it recognizes it as being pressed. This wasn't even a problem with the OS update. I was convinced when I tested it on the same Windows build version, the same drivers, the same CPU, multiple desktops and laptops of GPUs.

So once again, I don't know about programming.
But now this bug should be recognized in Photoshop as a user pressing "Spacebar" and then "unpressing" it (the Spacebar is not pressed), but it is not. Photoshop keeps thinking. The Spacebar order has come in, so I think I keep it.

Xilius

Participant

There is most definitely something happening in a way that the WM_LBUTTONUP is not triggered, or caught, rather. Unfortunately, there is not much I can say about this, without having a look at the source code. My wild guess is somewhere in a for or a while loop there is something which will shoot out of the WM_LBUTTONUP message processing. Everything resets to normal after first left click (without any other ley pressed).

Goyko

Participating Frequently

FINALLY you come up with some technical background!

I am sure, that helps some more technical competent people/users to encircle the topic even more.

And it also shows more openness and let us have some insight.

Thanks for that and good luck for isolating the bug piece by piece.

CJButler

Community Manager

Focusing on Windows 10 for a moment:

We don’t think the problem has anything to do with video cards.

There is an Event Queue that Photoshop polls as it works to handle commands like the Hand Tool and Panning, Creating a Selection, Painting and so on.

Looking at the panning gesture as a detailed example, That Event Queue holds the initial WM_LBUTTONDOWN event, followed by a series of WM_MOUSEMOVE events, followed by a WM_LBUTTONUP event. There are also periodic WM_KEYDOWN (the space key) which is referenced when initiating the mouse-down and figuring what Command to execute. Within Photoshop, this sequence of gestures initiates a Command (The Hand Tool), which then starts what is referred to as a Tracker. The Tracker is terminated when we see the WM_LBUTTONUP, and the panning gesture stops. This is how it is supposed to work. And in all our testing that is how it does work.

Even when you are an Artist working very quickly, the Windows OS Event Queue feeds us events, sometime a little out of order, but generally within a few milliseconds. We are supposed to see all the events in the above gesture.

Sometimes we get extra events, like when a Pen or other pointing device is involved. We can also get WM_POINTERDOWN and WM_POINTERUP, but even when working purely with a Pen, we still get the equivalent mouse events (Windows thoughtfully creates them and adds them to the Event Queue for us).

Our guess is that the Photoshop Tracker logic loop, for some reason, never gets to see the WM_LBUTTONUP event. We don’t know why, since we can’t reproduce the failure. For those of you with the problem, is Photoshop even getting the event? Is some sub-process consuming it silently and inappropriately? We just don’t know at this point.

MarinMarina

Participating Frequently

What I'm noticing is that the bug activates while click + key. Clicking (simple brush strokes for example) doesn't seem to have any issues, I clicked a ton with my brush, rapid clicking all over the canvas and everything was fine, the simple ctrl + drag was okay as well... the moment I used a alt or space + click/drag the bug started. When transforming a shape it's when ctrl + drag bugs out.

I'm an artist, I have to change brush size via alt + right click (also bugged) constantly, transform shapes on every single file. This bug renders 25.1 useless.

Xilius

Participant

Both my computers, the workstation and the PC have nVidia cards, 3060 TI and 3050 respectively. It may have to do with this, maybe. As for testing, try to switch fast and repeatedly from brush to hand tool for example and back again, panning all over the image as if repositioning constantly and FAST for brushing or whatever. Try using the spacebar while having brush selected, to activate the hand tool for paning, release it and use it again several times. Also, try to change brush size and hardness using the ALT + right click down several times. This should do the trick. The reproduction has to be done by an artist, rather than a software developer. I am both, fortunately, that's why I can make the distinction. If you are working fast on an image it's impossible not to replicate the bug within seconds.

CJButler

Community Manager

Please see my earlier posts in this thread. The current state has not meaningfully changed in the last several weeks. @Caity.psd would just be checking with me for updates.

The bug is Open/ToTest. We still cannot reliably reproduce at Adobe. We've seen the bug happen, but very infrequently and not all reliably, which makes it very difficult for us to diagnose the root cause. I understand this is contrary to the experience of many of the folks on this thread; for many of you, this happens all the time and is a productivity killer.

The normal sequence for handling a bug looks something like this:

New bug report
ToTest/Refine – we establish precise steps to reproduce (STR) the bug, allowing a Developer to debug the fail case.
ToFix – The Developer crafts a fix
ToTest/Verify – The fix is tested and verified that the STR no longer triggers the bug to occur.
Code Review – Other Developers review and approve the proposed code change.
Merge to Main Line code base
Automated testing, internal user testing
Prerelease, Beta Release – This is the first point end users can see the code change.
Official Release build with the fix.

We’re still on step 2. I'm still reading posts in this thread looking for information that might help get us into step 3.

oxpal

Participant

The strange trick outlined by @alfredoc1234 worked.

@Caity.psd Is Adobe actually having a "Fix in progress"? Like how many of your engeniers are on this since .... August? Nobody here even bothered to "keep you informed!", for all I see. Thank god the users helped.

Show more replies

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded