Switching tabs in Chrome requires mouse to slightly move for scroll to work

[menace97]

XMBC Version: 2.18.2
Windows Version: Windows 8.1 x64
Mouse Information (brand/model): Razer DeathAdder Elite
Did the problem occur after an upgrade of XMBC or Windows?: I noticed the issue only after upgrading to 2.18.1 or 2.182
How long have you used XMBC?: 5 years+
What language and keyboard layout do you use in Windows?: US-English

Clear description of the problem:
When switching between open tabs in Chrome 72.0.3626.96 x64 by CTRL-TABBING (so the location of the mouse pointer hasn't changed), scrolling with the mouse wheel does not do so. I need to slightly move the mouse to activate the scrolling action with the mouse wheel as it normally would perform.

After playing around with various settings that I had never tried, turning OFF "Make scroll wheel scroll window under cursor" seemed to restore the scrolling behavior within Chrome (I didn't need to move the mouse at all when switching tabs). The downside of this of course, is that as soon as I was hovering over a window in which I wanted to scroll, it of course wouldn't do so - I prefer having that setting ON. I thought I would mention my observations, as it may help with this issue for me.

NOTE: No extensions running in Chrome.

UPDATE:
Maybe something in Chrome changed this behavior? I tried going back to X-Mouse 2.16, 2.17 and 2.18... the issue was still present. I'm starting to second guess myself... I swear I didn't have to move the mouse at all to scroll web pages with the wheel before...

Thank you for your assistance!

[phil]

OK this makes some sense, because until you move the mouse, it does not detect the "window under the cursor" so when scrolling it is probably sending/redirecting the scroll message to the wrong (previous) window.

I will have a look and see if I can fix it (because using the keyboard alt+tab also runs the window detection, because obviously that can change the window under the cursor), I think the solution will be to simply do the same check when ctrl+tab is pressed as well as alt+tab). I'll let you know what I find.

I have reproduced the issue here (I'm at work at the moment so I can't do anything about it till I get home at best - I have a little list though as I was on Holiday in Canada last week and have a bit to catch up on - so I may not get to it straight away!). I'm a little surprised this issue was not present in older versions - I will have to check that (because if it was not, it may be a sign of more problems). I did attempt to reduce the amount of times the window check was performed (as its rather CPU intensive) but that shouldn't have made a difference in this regard.

Thanks,
Phil

[phil]

OK the same problem exists in 2.17 for me.
Anyway I have figured out the problem and fixed it - it will be in the next release.

[menace97]

Thank you so much Phil!

I hope you had a nice holiday here in Canada.

[phil]

I did indeed . Was in the Quebec (MontTremblant) area for skiing and snowmobiling .

[menace97]

Good to hear about your visit to Canada.

I wanted to update this to reflect another observation... I don't know how I missed it before, but this behavior occurs for me even when going BACK and FORWARD through browser history (so I don't necessarily need to switch to a new tab or window for this to occur). Being that I have a Razer DeathAdder Elite, I'm using the two side buttons to navigate back and forward through browser history - so if I don't move the mouse at all, push one of the side buttons to go back or forward, then use the mouse wheel to scroll... the page will not scroll. Again, like before, I only need to slightly move the position of the mouse pointer to again start scrolling the newly loaded web page (in the same tab/window).

I feel silly, as I'm just not sure that this ever happened before a short while ago. So I don't know if it's Windows, Chrome or with XMouse Button Control... or if it's just my imagination. Something lately just feels different with scrolling with the mouse wheel.

Thanks again!

[phil]

Yes, I know and understand the problem.
I think I have fixed it, Im just chasing another (unrelated) bug before I make another release.

[menace97]

Thank you Phil!

[phil]

Please try 2.18.3 (just released).

[menace97]

I just installed the new update, and I'm happy to say that switching tabs in Chrome doesn't require any movement of the mouse.

As I started browsing around in Chrome, testing out the new changes you made... I noticed that using either of my side buttons on my DeathAdder for going back and forward through browser history still required me to move the mouse position on the page slightly for the scroll wheel to kick-in.

I wanted to update this to reflect another observation... I don't know how I missed it before, but this behavior occurs for me even when going BACK and FORWARD through browser history (so I don't necessarily need to switch to a new tab or window for this to occur). Being that I have a Razer DeathAdder Elite, I'm using the two side buttons to navigate back and forward through browser history - so if I don't move the mouse at all, push one of the side buttons to go back or forward, then use the mouse wheel to scroll... the page will not scroll. Again, like before, I only need to slightly move the position of the mouse pointer to again start scrolling the newly loaded web page (in the same tab/window).

After messing around with going back and forward through browser history, I did manage to stumble upon something that might be helpful. If I did NOT use the mouse side buttons to go back and forward, but used the keyboard shortcut equivalents of ALT+Left Arrow and ALT + Right Arrow, and only use the mouse scroll wheel without moving the mouse itself, the webpage would nicely scroll - as then it seemed to correctly hold focus under the mouse pointer.

Many thanks!

[phil]

OK makes sense I guess.. The fix was to initiate a profile check when releating CTRL - it always did do a check when releasing ALT... So Alt+Left/Right always did a check. It does not initiate a check when pressing mouse buttons until the mouse moves.

This one will probably have to wait until 2.19 beta (which will probably be the next build) as this is certainly not a new bug in 2.18 (I don't think the previous one really was but that was less obvious ).

Regards,
Phil

[dinu]

Related to this, maybe it can have the same fix:

I'm also using the mose tilt buttons for tab navigations. However, I use {ACTIVATE} first because I have a multi-monitor setup and I want to switch tabs on the window under cursor. This fails in a different but seemingly related way: if quickly repeating the command (with {ACTIVATE} being the culprit), some background window gets activated and Ctrl-Tab sent to, with the effect of the current window losing focus and tilt button not working. If the repeat is slow enough, (~1s for me), the correct window is again activated on command. So probably {ACTIVATE} should do an active window check instead on relying on mouse-move or timer triggered cached window.

[phil]

I'm not sure this is related because this problem effect primarily the operation of the scroll wheel and "scroll window under cursor" option.
In this case, the window under the cursor changes, causing the scroll wheel to send scroll messages to the wrong (old) window.

You seem to be talking about something (in my mind) completely different. Or are you in fact talking about the use of the scroll wheel after using the activate tag? That's the only way this could be related and in that case I apologize for jumping to conclusions. It seems in fact that your problem is the wrong window is getting activated and nothing at all to do with the scroll wheel not working, so really this deserves its own topic where we can discuss the particular detail and required diagnostic for this.

I know that the activate is not 100% perfect - this could be more related to the problem I couldn't fix where a window gets activated but does not somehow grab keyboard focus, so does not receive the key commands (even sent from the keyboard). Fortunately the debug logging does log quite a bit of info regarding activation, and what window it is activating - so first I thin capturing this problem with debug enabled would be a good start and might help me narrow down the problem.

Thanks,
Phil

[menace97]

OK makes sense I guess.. The fix was to initiate a profile check when releating CTRL - it always did do a check when releasing ALT... So Alt+Left/Right always did a check. It does not initiate a check when pressing mouse buttons until the mouse moves.

This one will probably have to wait until 2.19 beta (which will probably be the next build) as this is certainly not a new bug in 2.18 (I don't think the previous one really was but that was less obvious ).

Regards,
Phil

Thank you Phil

[phil]

Actually it will be improved in the next release 2.18.4 (maybe along with the activate issue mentioned above) as I spent mostof my day off yesterday tinkering with it! I cant guarantee it will be perfect yet - it was a bit of a timing pain/nightmare - because the profile check is done on a timer, I have kicked off the timer when a button is released (as well as when the mouse is moved) but had lots of issues when scrolling before (or during) the timer being executed. I think I have overcome most of the issues but it remains to be seen how well it works.

Incidentally, if you have Windows 10, it may actually be better to turn off the "scroll window under cursor" in XMBC global settings and use the Windows setting instead - assuming you don't want to control it per-profile! I think it is turned on by default anyway in Win 10 (although that may depend on what version you have I guess) but there is a setting in the new mouse setting applet to turn on/off.