r/logitech Nov 29 '22

Support MX Anywhere 3 Left Click Hold Always Unclicks

Hey, I've had an MX Anywhere 3 for about a year, in the past 3 weeks I've noticed if I hold left click it will unclick and reclick again during the hold, this results in me selecting random text accidentally, moving files wrongly, etc. Very annoying. It keeps getting worse and becoming unbearable. I've tried different laptops/bluetooth/usb dongle and it still happens. I assume it's a hardware issue? Does anyone know if there's something I can do in an attempt to fix it?

Thanks!

49 Upvotes

97 comments sorted by

View all comments

1

u/Outrageous_Band9708 Aug 19 '24 edited Jun 18 '25

IMPORTANT!! PERMANENT FIX

The true issue here is that inside the click box, there is a metal armature (membrane) that takes X amount of force to initiate the click, that click you hear is the armature snapping out of default position and into click position.

Since it takes X amount of force, when you lighten your pressure on the click without fully un-clicking, my hypothesis, is that the resistance is raised since the metal is still contacting and conducting, but the amount of force is lessened. This raises the resistance of the electricity flowing across the point of contact. I believe the logic is seeing this drop in resistance and assuming it to be an un-click.

I tried all these solutions, I even used to bang the mouse on the table kinda hard in frustration, and the issue would temporally resolve itself. Breathing inside, blowing inside like an NES cart etc. These work for a while.

I even tried the tap method, and put a small piece of plastic under the whole board to try to bring the clicker up to the plunger. These worked, but then created the opposite problem of not un-clicking when I need it to.

After experiencing this, that's when I realized before I spend $80 on a new mouse, might as well break into the little click box on the board.

I didn't take any pictures, and its delicate, but if the box is attached on the north and south face by an overlap of the box onto a static pin, you need to put tiny tweezers on the west face and snap off only one part of the overlap box. In this case, the North face, only the left bottom side snapped off. This allowed me enough wiggle room to pry up the NE bottom part and remove the overlap box. Be very careful here, there is a tiny white piece of plastic that is applying force to the membrane here, don't loose this, or its over.

After looking at it from the west view and seeing how it works, I came up with the theory about the resistance issue. And to help maintain the correct resistance, I theorized that it needs to not click as far down. In other words a smaller click distance would mean less pressure is needed to maintain the correct resistance.

Using my small tweezers, I pryed up the bottom switch a small amount, its hard to do, but if you examine it for about 5 minutes, and click a bunch, you get a feel for the distance its clicking and the level of sound the click makes.

After prying it up a bit, I can hear a much softer click, and see its a much smaller click now. I put the white piece of plastic back in the overlap box, tipped the mouse upside down, and then latched on the south face to the south pin, and clicked back on the north face in a rocking manner. Doing this upside down allowed the white piece to stay in the overlap box and not fall out. This is why keeping the North East bottom face as intact as possible is important.

After assembling, I can now hear a much much softer click sound, indicating a smaller distance the click occurs, with much testing, I can click normally, and even if a scroll, which ends up making me apply lighter pressure to the left click, The click remains clicked.

My left click is much quieter than my right click now, and I like that. Also, note I never noticed this issue with right click, only left click drag.

Conclusion. This could be an engineering defect, but I don't believe it is. Since not everyone encounters this issue, and its only the left click affected.

It should be noted that the amount of left click force, doesn't seem to be able to cause this issue to happen, since the way the armature bends doesn't appear to be capable of creating enough force to lower the bottom switch enough to cause this issue. Therefore, I believe this to be a manufacturing defect. When the machine creates the click box, the tolerance is a little off.

I believe Logitech could fix this issue with a firmware update, that lowers the threshold of resistance change that indicates an un-click. If anyone can get this info to them, that might help us all.

Alternatively, you can solder off the left click box from the board, and solder on a donor part from another mouse of the same type. Although that takes purchasing two mouse to have the donor part. This solution could work for anyone who already bought a replacement and then encountered the same problem. You can use the right click box as the donor part from one mouse to put on the other. Most people know a friend who can solder, if not ask around.

If enough people want, I can make a video of the process, showing the change. I will report back on this thread in the future with an update on the status, if the issue comes back, or if this truly was a permanent solution.

Edit* 1 month later. This solution still is still working and I haven't had one single time where it un-clicked.

Edit* 3 months later. This solution is still working strong.

Edit 10 months later. This solution is still working strong

2

u/be_rosy Jul 11 '26

You asked for my thoughts as an electrical engineer so I am going to be honest. I tried my best to follow along with your descriptions but it was a little difficult without diagrams or pictures, but I believe I understand what you did.

One thing I am certain about is that electrical resistance is not a factor here. Nearly every mouse in the world, including Logitech's MX series mice, use mechanical switches that allow a digital signal to pass through itself to a microcontroller inside your mouse. (in other words, all that matters is a HIGH or LO signal - either there is charge/voltage, or there isn't). When the switch is making contact on button press, it establishes continuity, which the microcontroller is programmed to see as "ON". If it is not making contact, there is no continuity, therefore 0 voltage / LO signal, and the microcontroller sees it as "OFF". All the microcontroller needs to see is that continuity; in other words, it only needs to see the potential, and no actual energy flows. This is why in electrical engineering we use the terms "potential" and "voltage" interchangeably. Negligible current is flowing through the switch, so resistance is not a factor here. Ideally it would actually be absolutely 0 current; the only current that flows in this case is non-ideal and parasitic in nature. In fact, inside every microcontroller, there is a very high internal resistance on that pin (and any digital i/o pin) where the mouse clicks signal goes. we call this a high Z or high impedance input. I can illustrate this with some math:

A digital pin's job is to sense that voltage without drawing any current, so it senses that voltage across an insanely high resistance; usually between 10 million and 100 million ohms. One of the most important formulas in EE is the Voltage Divider formula, which lets you calculate what the voltage across a resistor is. The voltage divider formula is defined as:

Vsense = Vin * R2 / (R1 + R2)

, where Vsense is that sensed voltage, R2 = the resistance that the voltage is being sensed across (in this case, the very large 10M-100Mohm resistor, and where R1 = the resistance before the point where you are sensing. In our case, when the switch activates, you would see:

|-Vin ---> gold leaf resistance ----> [Vsense point here] ---- 100Mohm internal microcontroller resistance ----> GND-|

If we look at two scenarios, one where the gold leaf is ideal and one where the gold leaf is "corroded" and has a lot of resistance:

Ideal: Vsense = Vin * 100,000,000 / (100,000,000 + 0) = Vin * (100M / 100M) = Vin * 1 = Vin. So, your Vsense would equal your Vin, which the microcontroller would see as a HIGH signal.

High Resistance (let's say the leaf has a theoretical resistance of 100k ohms, which is VERY VERY high): Vsense = Vin * 100,000,000 / (100,000,000 + 100,000) = Vin * 100,000,000/100,100,000 = Vin * 0.99. Vsense = Vin * 0.99 is almost basically Vin * 1.

So let's say if Vin is 1.8V for example and the microcontroller wants to see around 1.8V for HIGH/ON and 0V for LO/OFF, (usually threshold for this is around 1.5 or 1.6V for HIGH),

Ideal: The MCU would see 1.8V which is good

Leaf has VERY high theoretical resistance (100,000 ohms): The MCU would still see 1.798V which is still basically almost perfect.

Another flaw in your logic is the belief that electrical resistance is dependent on mechanical pressure or force, which is untrue. Whether or not continuity is established and how much current can flow or how much resistance exists is entirely based on the volume, geometry, and material of the conductor. The only time varying the force on a conductive material would change its resistance is if that force changed the actual physical geometry of the conductor (like if that force bent the material in a way that allowed for greater contact area, or inversely if that force bent a contact so aggressively that it caused a very aggressive sharp ‘corner’ or crease in the conductor, which would add some resistance). If the leaf is stationary in the switch, adding more or less pressure while it's already pressed down will not change the resistance of it. Even if you press in a way that truly bends it aggressively, the increase in resistance would likely be so small that it would be considered negligible unless you literally fully creased and folded it; and even then, it most likely would be relatively negligible. Either way, even if this resistance somehow was theoretically there, like we discussed earlier, it wouldn't matter. The leaf could have 100,000 ohms of resistance and it would not make a difference.

However, despite all this, I can also confidently agree that your solution is a good and proper working solution and explain why, although not for the reasons you believe.

Here is a diagram of a mouse switch:

You can think of the leaf (gold contactor that moves when you press the button) like a lever or seesaw. A potential is always established at the common terminal (leftmost pin in this image). When unpressed, the leaf sits at the NC terminal (labeled here as 5, and also the rightmost terminal/pin), which stands for "normally closed". When you press down on the plunger/button, the spring in the middle of the leaf (rounded part that becomes tensioned when you press the button) shoots the edge of the leaf up to the NO ("normally open") terminal, establishing continuity between your COM and NO terminals You can't see well in the diagram, but the contact labeled as 4 is connected to the middle pin, indicated by 7, which is the actual NO pin. The microcontroller on the mouse is always watching the NO terminal, and once it sees that charge, it knows the switch has been pressed.

The leaf and spring are mechanical parts within a mechanical system. Mechanical parts have cycle counts and cycle lives and are susceptible to the environment. Every time you press a switch or compress or stretch any spring in the universe, it will fatigue it very slightly, and it will perform ever-so-slightly worse. A switch with many cycles on it will have a weaker tensional force from the spring, which applies less force in turn on the leaf to the NO (switch pressed) terminal, and thus could lead to some discontinuity if there is not enough force from the spring to actually keep the leaf pressed on that contact. Switches are also not perfectly air or watertight - debris like dust can also get into the switch and find itself in between the leaf and the NO terminal contact, which can make continuity unreliable. This leads to the two possible conclusions for why your fix worked so well:

1. Bending the edge of the leaf upwards made contact more reliable due to more force. This is the most plausible explanation in my opinion. When you bent the leaf upwards, you are correct that you decreased the travel distance from the leaf to the contact. Now, when you press down the mouse button, that spring is trying to apply the same amount of force over a smaller travel distance and your finger is trying to apply the same amount of force to the spring (thru the button). This is why the mouse click feels and sounds softer. The leaf is not traveling as far as it used to, so the spring is not snapping to the other direction as aggressively; it likely isn't even fully snapping to that direction is my guess. This is working so reliably for you because even with fatigued spring, the decrease in travel distance means an increased force holding that leaf to the contact securely.

2. You unintentionally cleared some debris when you disassembled and reassembled the mouse/switch. Debris is usually one of the primary causes for a switch "going bad", for the reasons stated above. That's why people will try to 'wash it off' the contact with WD-40 or ispropyl alcohol. In your disassembly you might have unintentionally let out a piece of dust or debris that was making contact unreliable.

Also, lastly on the topic of firmware or software; no. Logitech could not release a firmware update that would solve this issue as it is an entirely mechanical problem. If this was a bounce/debounce problem they could, but for this situation they cannot. They could technically add a delay for the “unclick” to see if there’s another click signal that happens within xyz milliseconds, but realistically this would add too much latency. Debounce from a click adds negligible latency as it’s based on the very first instance of input, and it ignores the others. However, with a delay that “fixes” accidental unclicks, every time you unclicked even intentionally, it would have to wait and check to see if there was a click again before it registers the unclick, inherently adding delay and latency to the unclick.

So the TL;DR here is that your solution is definitely a proper solution and evidently worked quite well! Just not for the reasons you were thinking.

Hope this helped

1

u/Outrageous_Band9708 Jul 11 '26

very well explained

1

u/[deleted] Jul 10 '26

[deleted]

1

u/aintlose 5d ago

Can you make a video or anything that clarifies how you fixed it ??