Using classic Outlook for Windows in business environments
I closed out of Outlook in hopes that it would be fixed. Re-launched Outlook. No change.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
The vertical scroll bar on the far right of my Outlook.com window keeps jumping to the bottom of the screen whenever I click on one of my folders or an email. Then I can't see the ribbon above my emails. I push the scroll bar back to the top, but as soon as I click on a folder again, it jumps back to the bottom of the screen. It happens whether my zoom is at 100% or higher. I tried the repair option and restarting. I contacted Outlook Support and after 40 minutes, they said it's how Outlook is designed and can't be fixed. But it wasn't always this way and just started jumping. I see there was a related issue that was fixed in Feb 2025: https://answers.microsoft.com/en-us/outlook_com/forum/all/issue-with-the-inbox-scrolling-bar/ce34dda6-7f02-4222-8c44-62b2d2ea485d
I am using a laptop. The issue is present in Chrome and Edge.
Using classic Outlook for Windows in business environments
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
I closed out of Outlook in hopes that it would be fixed. Re-launched Outlook. No change.
I'm now using a USB mouse. After about 1 hour of use, I have yet to see it exhibit the scrolling defect that was increasingly-frequent in my bluetooth mouse.
I dunno yet whether it's a hardware issue, or a software one (due to the difference between the driver-stack in a USB vs a bluetooth connection to a mouse). I'm thinking it's most-likely a hardware fault; anyway on my round-to-it list is to purchase another bluetooth mouse. I'll post my findings here.
Mice are not 100% reliable!
Your mileage may vary, but my issue is now sorted -- with a new bluetooth mouse!
If you are still having difficulty with the mouse-scrolling misbehaviour, I'd recommend you try a different mouse. You too might find that the old mouse was the root cause of this very annoying & mystifying usability defect.
I have now had 1 week of faultfree operation with this newly-purchased mouse.
My old USB mouse worked fine too, but its dongle was annoying.
I'm posting today because, when I reconnected my old bluetooth mouse, it immediately misbehaved. This makes me very confident that the issue was with the old mouse, and not with any software. (It's hard to diagnose these intermittent defects, especially when software e.g. in the browser can (and is!) updated at any time without any obvious notice.)
Just over a week ago, I had opened up the misbehaving bluetooth mouse (which wasn't easy, it's not designed to be repairable), I had seen some tiny hairs on the spoked wheel which (to the best of my understanding) has a photoelectric sensor to detect whenever the wheel is spinning. I tried to clean it out but it still misbehaved... so I purchased a new mouse.
I hope a new mouse sorts the problem for you too!
I am not using a mouse. This would lead me to believe it is a software issue.
OK, since the mouse-stutter defect was resolved on my platform by shifting to a different mouse, and since it also arises on at least one rodent-free platform, I now have a new theory about the root cause.
Under my new theory: switching to a different pointing device *might* be an adequate workaround for your platform. No guarantees.
tl;dr
Some process may be corrupting the event queue in Windows, perhaps by "peeking" at a mouse event on the raw-input queue, then pushing it back onto the queue after determining (quite possibly correctly) that this event really "should" be handled by some other process. Due to a race condition (?) some other process also gets a copy of this mouse event, and then pushes its copy onto the queue. Hey presto, there may now be three events for a single mouse click or scroll. (Why three? Well unless the RIDEV_NOLEGACY flag is set when a process registers its "raw input" handler for the pointing device, the mouse's driver will still put a "legacy" event on the queue every time the mouse's status changes.) My source for this tech-geek info is
https://ph3at.github.io/posts/Windows-Input/
Weakly supporting evidence for my new theory is that for some months now my platform has been pretty iffy about restoring its mouse device after it goes into one of its deeper modes of sleep/hibernation. It's more than a bit awkward to use the Windows GUI without a pointing device, but it's possible... and usually I can "manually" bash the OS around until it deigns to load a functional stack of mouse drivers. Sometimes a reboot is required. Sometimes it seems I must disable and then re-enable Bluetooth before I'll get any joy (last night was especially annoying, with a Bluetooth mouse that would momentarily be accepted by the OS only to be shown as disconnected a fraction of a second later.)
All to say that I think there are some gnarly race conditions that'll have to be sorted before this defect is put to rest.
In the meantime (and it may take the Windows QA team quite a while to localise & repair this defect if it is indeed a race condition), I'm suggesting that a viable workaround for your platform *might* be to switch to a different pointing device.``
I was actually able to solve this on my laptop anyway.
In my browser settings I reduced "page zoom" from 100% to 90%. The scroll bar to the far right is no longer there
so no more losing the ribbon when deleting messages or switching between folders.
Down side is the page and font is a little bit smaller.