Mouse hold & drag test
Hold any mouse button and drag back and forth in the area below for ten-odd seconds, then let go. For every hold the page checks whether the signal ever cut out and pressed again — which is exactly what drops a dragged file mid-way. The left, middle and right buttons and both side buttons all work, and the tracking carries on even if the pointer leaves the area mid-hold.
Hold stability
WaitingPress and hold the area below for 5 seconds without letting go. The left, middle and right buttons and both side buttons all work, and the result names the button you used. If the signal drops out even once, the timer stops on the spot — with no dragging to distract it, this is the most direct check for “it cuts out while held”. Letting go early also counts as one failure; just retry. If a side button does nothing at all, the driver probably does not report it as a mouse button — that means “not received”, not a pass.
Broken down by button
All five buttons are listed below. A dash means this button received no events at all — either it was never tested, or the mouse or driver never reported it as a mouse button. That is not the same as 0 presses. The row for a button highlights while it is held.
| Button | Holds | Suspected dropout | Longest (ms) |
|---|---|---|---|
| Left | — | — | — |
| Middle | — | — | — |
| Right | — | — | — |
| Side 4 | — | — | — |
| Side 5 | — | — | — |
Drag log
The last 10 drags, newest first. The ones in red had a dropout detected in them.
What this test cannot tell you
- A browser has no “button dropout” signal. A break mid-press shows up in the event stream as one release plus one press, exactly the same as the user really letting go and pressing again; no field tells the two apart. All the page can do is look for behavioural clues: a human hand cannot press again in place within 90 milliseconds, so only the holds that are “extremely short + barely moved” are counted as a suspected dropout.
- The verdict is yours to make. If you are certain you never let go and it reports a dropout, that mouse’s button signal really did cut out. Conversely, if you did change hands or let go briefly, what it reports is your own doing. The duration and distance on each log line can help you remember what you were doing at the time.
- One class of buttons never reaches the page. On some mice the side buttons are sent by the driver as keyboard events, and some browsers do not let a web page cancel a side button’s back/forward. The row then stays empty (a dash), and empty is not “0 presses” — it is “not measured”. The two look identical in the data and mean opposite things.
- The browser takes the right button for itself. Edge has a built-in “mouse gestures” feature that reads holding the right button and dragging as drawing a gesture: a blue line is drawn on screen as you go, and that trail is not drawn by this page. There is nothing a web page can do to stop it (Microsoft has confirmed this — not even a command-line switch turns it off). What makes it worse than the other two is that once the shape is complete the browser performs the action outright (go back, close a tab), the whole page jumps away and the reading you just took is gone. It is on by default in Edge in China; turn it off at edge://settings/mouseGesture — see the last question below for the details.
How this relates to a drag being dropped
A file that drops mid-drag has usually hit a dropout during the hold: the system received “released” and set the file down at the pointer’s position at that moment. The same dropout is almost invisible in an ordinary click (at most it might miss a click now and then), but in a drag it shows at once — which is why this test is more sensitive than a click test.
Common questions
It measures “released and then pressed again in place, extremely fast”. Two conditions have to hold at once: the gap is shorter than 90 milliseconds, and the pointer moved no more than 4 pixels. A human hand cannot do this — the fastest double-click is still over 60 milliseconds, and the mouse shifts under the recoil. So a hold meeting both conditions is almost certainly the button signal cutting out on its own.
Because a browser has no “button dropout” signal at all. A break mid-press is one release plus one press in the event stream, exactly the same as the user really letting go and pressing again, and no field separates the two. All there is to go on is behaviour, and behaviour is not proof. So the reading is yours to make: if you are sure you never let go and it reports a dropout, that mouse is the problem.
The metal contacts of a switch oxidise and wear after a few thousand clicks, the contact becomes unreliable, and holding it still can lose contact for an instant: the system gets a “release” and immediately after a “press”, and the file you were dragging falls half-way. It is invisible in an ordinary click — a click lasts only tens of milliseconds, while a drag holds for several seconds, and the longer you hold the more likely you are to hit that instant. It is one of two faces of the same root cause as double-clicking (one press firing twice): the same worn pair of contacts can either chatter out an extra click or break while held, so the two often appear together. If this page reports a suspected dropout and the double-click page reports chatter at the same time, you can safely put it down to a worn switch rather than the browser or the driver. The real fix is a new switch (common brands are Omron, Kailh and Huano), or a warranty repair.
Yes, and that is its main use. A dragged file that drops mid-way usually means a dropout happened during the hold — the system received “released” and dropped the file at that position. The way to test is to hold the left button and drag back and forth in this area for ten-odd seconds, then release and check whether that drag’s dropout count is 0. Be careful not to count window focus loss: press Alt+Tab and the system really does think you let go, and that is not the mouse’s fault.
The left, middle and right buttons and both side buttons can all be tested — whichever button you hold is recorded under that button, and holding several at once is told apart too. But the side buttons have two preconditions, and without them that row shows a dash (not measured) rather than 0. First, on some mice the side buttons are not reported as mouse buttons at all — the vendor driver sends them as keyboard events or a macro, the browser receives no mouse event, and there is nothing for the page to measure. Second, some browsers do not let a web page cancel a side button’s back/forward, so one press sends the whole page away. Both cases mean only “the page received nothing”, not that the button was pressed 0 times — and lumping the two into one number is exactly where this kind of test most easily misleads.
No, and this page cannot block it. It is Edge’s built-in “mouse gestures”: it reads “hold the right button and drag” as drawing a gesture and draws the trail on screen as it goes. It is not the right-click menu, so none of the usual ways a page suppresses that menu touch it — Microsoft has confirmed there is no way to turn it off from a web page. What matters more is that it does not just draw a line: once the shape is complete the browser performs the action outright (go back, close a tab, and so on), the whole page jumps away and the reading you just took is gone. It is on by default in Edge in China; turn it off by entering edge://settings/mouseGesture in the address bar and switching off the master toggle — or, if you would rather not turn it off everywhere, add this site to the block list under “Configure mouse gestures” on the same page so it applies here only. Chrome and other browsers have no such feature and are unaffected.
If the page never received the release event after you let go (because the pointer was released outside the browser window, say), that stretch shows as never having ended. That is an honest report, not an error — the page can only know what it received.
