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

x64 Replacement/Alternative to Microsoft's IntelliMouse application.
Forum rules
Please read the forum rules before posting for the first time.
The more information you can provide, the quicker and more accurately someone can help.
NOTE: To reduce spam, new users can not post links, files or images until they have at least 4 posts.
dinu
Member
Posts: 23
Joined: Mon Jul 17, 2017 9:09 am

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

Post by dinu »

Well, in my mind they were related in the sense that in both cases the messages are sent to another window than the one under cursor and it seems in both cases re-detecting the top window under cursor would fix the problem, but I don't know the inner workings...

Yes, it also involves scroll. To reproduce: bind {ACTIVATE}{CTRL}{TAB} to mouse tilt button.
After using, the scroll is broken until mouse move AND a subsequent tilt will not work (will actually trigger window to lose focus) for about 1 second. So it seems the culprit is the same, sending messages to a wrong cached window.

Note: For me, Ctrl-Tab (from keyboard, or without activate) followed by scroll works with 2.18.3. Only {ACTIVATE} breaks it.

Note: I wanted to install 2.18.4 but both Window Defender and Panda Dome slapped my hand. Can you check? I just have a "suspicious file" warning and an automated quarantine, without any particular details, from both. Actually Panda lists a generic "W32/Exploit.gen" detection.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

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

Post by phil »

I will check but I think you will find that it is a false positive. Unfortunately its quite common (especially if you use NSIS installer like XMBC does) with brand new files that have only been up for a few hours. It takes a while for AV to start trusting. In this case its also a new signing certificate new issue as the old one expired (or expires this week) so perhaps more "suspicious" lol.

PS. was this an auto "check for updates" or a download from the website? there are different packages (the update is much smaller as it only contains the changed application file(s).
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
dinu
Member
Posts: 23
Joined: Mon Jul 17, 2017 9:09 am

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

Post by dinu »

Download from site, full installer.
Updating from the context menu worked, so it's probably the installer.
{ACTIVATE} still broken in 2.18.4 for me, same symptoms: {ACTIVATE}{CTRL}{TAB} followed by scroll doesn't work, followed by same doesn't work, loses focus.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

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

Post by phil »

Well I'm not really surprised. As I said they are actually two rather different issues internally.

I did modify the code to do fire the profile detection timer after activate occurs - but firstly, that timer fires after about (250ms) so your CTRL+TAB will run before the timer and secondly, assuming you have "detect profile on mouse hover" enabled then the correct profile will already be active...

Out of interest, does it make any difference if you add a delay between {ACTIVATE} and {CTRL}{TAB}...
Like {ACTIVATE}{WAITMS:400}{CTRL}{TAB} ??

There appears to be a general issue here with the {activate} tag in that it does not seem to work reliably. This is probably because the API that I call to activate the window is not supported or documented by MS (they don't want people doing this sort of thing - There is no documented API to do this) and as such, its likely to be fragile! It also seems that when I ask Windows for the the window under the cursor, it does not always return a valid window (esp. in that case of chrome and back/next because the chrome process changes between tabs, if XMBC asks too quickly, e.g. during the transition between "tabs" it returns weird invalid window handles (presumably very temporary windows that chrome creates to do some funky animation or something). For scrolling, I can just ignore the window handle if its invalid and not redirect scroll (which is what I did) but for actual activation, god know what will happen.

If adding the wait does not help, I'm afraid this one will have to go on the beta pile - as its going to need some thorough investigation and testing! You'd be welcome to help out there. It would also be perhaps useful for you to detail steps to reproduce (maybe a copy of the profile) and also to produce some debug log of the current (2.18.3 / 2.18.4) version to see if there are any obvious things in the log.
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
dinu
Member
Posts: 23
Joined: Mon Jul 17, 2017 9:09 am

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

Post by dinu »

Umm,
I think the window identification should run before the {ACTIVATE}, not after. With 400ms delay I can't test, because like I said, it seems to work naturally after ~1s, which can be also ~0.5s, and my finger timing isn't that accurate.
BUT I don't see how it can work if it runs after {ACTIVATE}: the problem here is the {ACTIVATE} is activationg the wrong window: without {ACTIVATE} everything works like a charm. So it's the {ACTIVATE} the problem, not the {CTRL}{TAB}. So in my mind, the window detection should run before {ACTIVATE}.

To reiterate the scenario I'm seing:

I am on TAB1 (WH1) (active) - XMBC knows WH1 is active.
1) {ACTIVATE} - does nothing
2) {CTRL}{TAB} - Chrome activates TAB2 (WH2) - XMBC is still on WH1
3) {ACTIVATE} - activates WH1 (windowsless); WH2 loses focus
4) {CTRL}{TAB}, scroll etc - does nothing
5) Some timer runs, XMBC updates active to WH2 ( after ~1s, maybe less with your last changes )

Fixing this would require the window identification to run before 3) above, so before {ACTIVATE}.

Note, here a 250ms fix hack would not be an acceptable result anyway, because one, I click faster that that when I want to switch tabs and two, the window loses focus when that happens which is more dramatic than just waiting 250ms for the scroll to resume working. Being out of focus, nothing gets sent to it (keyboard, mouse, nothing works anymore: Ctrl-W, Home, End, Ctrl-PgUp, anything). It's just stalled, I need to click it to resume any interaction. So I think the detection needs to be called explicitly before {ACTIVATE}, not with a timer after {CTRL}{TAB}, in this scenario.

As about the doubts about the activation mechanism: it works in principle. If I wait the second and then {ACTIVATE}{CTRL}{TAB} again, normal operation resumes. So the subsequent {ACTIVATE} works, but only if it tries to activate the right thing.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

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

Post by phil »

Of course the window detection runs before activate (it runs when the mouse cursor moves) - else it wouldn't find the correct profile and run that macro! But if activate changes input focus, it now runs the window detection again - on the off chance that the window changes.

If it does not change then there should be no problem. But this comes back to the fact that this is NOT the same bug which was because window detentions was not running and the back/next page in chrome caused the window to change and the scroll messages to go to the wrong (not active) window. As I said earlier I have had problems with activating other processes and that's more likely the problem here, not the window/profile detection!
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
menace97
New User
Posts: 10
Joined: Mon Nov 07, 2016 12:01 am

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

Post by menace97 »

2.18.4 seems to have fixed both of the issues I was having. I've just done some initial testing, but so far everything is working perfectly!

Thank you so much Phil :D
dinu
Member
Posts: 23
Joined: Mon Jul 17, 2017 9:09 am

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

Post by dinu »

phil wrote: Fri Mar 01, 2019 7:36 pm Of course the window detection runs before activate (it runs when the mouse cursor moves) - else it wouldn't find the correct profile and run that macro!
No, no - in the above scenario, the mouse does NOT move between steps 2 and 3.
If the mouse moves, everything works.
So, the activation crashes on step 3 because it's still trying to activate the old window. There doesn't seem to be an explicit detection immediately before {ACTIVATE}, it's relying on timer and mouse move to update.
Actually wrong wrote:But, your description of the {ACTIVATE} sequence did provide me with a hack:
{ACTIVATE}{CTRL}{TAB}{ACTIVATE} works, because the second {ACTIVATE} forces XMBC to update the active handle as you described - after it runs.
With this hack, everything works like a charm - but I still think you should run the detection before {ACTIVATE}, it would be so much more intuitive.
LE: Strike the previous paragraph - it doesn't work, it seemed to work in a bout of enthusiasm :) [s][/s] doesn't work so I quoted it to stand it out.
Last edited by dinu on Wed Mar 06, 2019 2:08 am, edited 1 time in total.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

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

Post by phil »

Have you tried 2.18.5 yet - it should be fixed (I released it anyway as there was another biggie yesterday and you hadn't responded to my PM about giving it a try first)

The issue is not the profile detection (which is what happens when the mouse moves) - the issue is with the activate and the window under the cursor detection (which again obviously has to (and does) run before the activate, otherwise how would it know what to activate). The problem is when chrome switches tabs, there are ghost windows that Windows itself reports as the window under the cursor (which is not true or true for a very small amount of time). In this case, it caused XMBC to activate the wrong (ghost) window - which takes focus away from everything else and therefore the problem you described.

So I have had to essentially detect and work around this by doing more tests on the window returned to make sure it is a genuine window and not disabled/invisible. It took some testing but I thought I had got it in the end. So if you haven't tried 2.18.5 I Would appreciate you checking it and letting me know - if you have tried it and it still does not work, I'm at a bit of a loss as to where to turn next.
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
dinu
Member
Posts: 23
Joined: Mon Jul 17, 2017 9:09 am

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

Post by dinu »

Yipe! I confirm it works now, thanks!
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

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

Post by phil »

Great (and phew!).
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
dinu
Member
Posts: 23
Joined: Mon Jul 17, 2017 9:09 am

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

Post by dinu »

Umm... sorry, it seems no "phew" yet:
Now tabs change but it seems because of a new bug: {ACTIVATE} doesn't work anymore with Chrome: it always sends the {CTRL}{TAB} to the active window, even when my mouse is on top of another. Doesn't involve repeated commands. Steps:

1) Activate a Chrome window
2) Move the mouse over another window
3) {ACTIVATE}{CTRL}{TAB} - switches the tab without problems, but on the active window, not the one under the mouse
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

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

Post by phil »

Arghhh I didn't try it with two separate chrome windows open :(. OK that scenario kind'a rules out my work-around...
Which may be a problem - in that its going to make it tricky/near impossible to detect this ghosted window problem.

Either way I'm not going to be able to look at this now until at best Sunday (and that will be with a stinking hangover so probably next week!).
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
dinu
Member
Posts: 23
Joined: Mon Jul 17, 2017 9:09 am

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

Post by dinu »

Hahah. No worries, I've been using it like this for a while now, I got used to it... makes life more interesting.
Enjoy your before-hangover time!
dinu
Member
Posts: 23
Joined: Mon Jul 17, 2017 9:09 am

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

Post by dinu »

Just... is there some place I can download the previous version? :D
Post Reply