Issue about default focus

[haokuixi]

I found that, by default, focus moves to the first tab after selecting any tab via QuicKey.

This is inconvenient for users who use the Vimium extension.

[fwextensions]

Thanks for the bug report!

I’ve never seen that behavior, even when testing on macOS. Which version are you on? I think my test box is on 10.12 or .13, both of which are old. But I wouldn’t think that would affect Chrome’s behavior much. Which version of Chrome are you on?

It’s possible this is caused by a bad interaction with Vimium. If you turn it off (you can go into the Extensions page and click the toggle next to it, without uninstalling it), does this focus bug still happen? I’ll do some testing with it, too, though I’m out of town so it’ll be a bit delayed.

[haokuixi]

macOS version: 10.14
Chrome version: 75.0.3770.100
QuicKey version: 1.1.0

I turned off all extensions, except QuicKey, but the focus bug still exist. Also I tested under Incognito mode with only QuicKey enabled and the issue remains the same.

[fwextensions]

Thanks for the testing, I appreciate it!

Just so I understand, if you select, say, the third tab in a window using QuicKey, what happens?

1. Tab 3 is visible, but the keyboard focus is on the tab control for tab 1 (the blue outline).
2. Tab 1 is visible, and the keyboard focus is on the tab control for tab 1.

I’d been assuming result #1, but the screenshot looks maybe like #2.

Do you see a difference between navigating to a previous tab using the CTRL-A shortcut vs pressing CTRL-Q, typing a tab name and then pressing enter to switch to it via the popup menu? They should be the same, but the two flows have slightly different code paths.

[fwextensions]

I still can't reproduce it (it'll be several days before I can test on a Mac), but I have at least a theory of what might be causing it (though I've never seen it behave that way on Mac or Windows).

I realized that my code for checking whether the tab you're focusing is in the current window or not has always been buggy, but it's never caused any issues for me. Basically, whenever you choose a tab to focus, it always also focuses the tab's window. It's supposed to do that only if the tab isn't in the current window. Conceptually, it's not crazy that focusing an already focused window could have some additional effect, though again I've never seen it.

Do you have any accessibility features turned on in macOS, or any OS utilities that affect keyboard focus? It feels like something outside of Chrome is moving the focus, so I'm wondering if there's some utility that automatically focuses the first element in a window when the window is moved to the front. In the case of Chrome, I think that would be the first tab.

I don't know how familiar you are with programming Chrome extensions, but if you wanted to try modifying a local copy of QuicKey, then commenting out these two lines may fix the issue:

https://github.com/fwextensions/QuicKey/blob/master/src/js/background/recent-tabs.js#L425

https://github.com/fwextensions/QuicKey/blob/master/src/js/popup/app.js#L243

If you have more than one window open, commenting out these lines means switching to a tab in a background window won't focus that window, but if you just have one window, you'll avoid the unnecessary focus call.

[fwextensions]

Also, I tried installing Vimium, but I can't reproduce the focus issues on Windows. After switching to a tab with QuicKey, the Vimium keys still work.

[haokuixi]

Thanks for the testing, I appreciate it!

Just so I understand, if you select, say, the third tab in a window using QuicKey, what happens?

1. Tab 3 is visible, but the keyboard focus is on the tab control for tab 1 (the blue outline).
2. Tab 1 is visible, and the keyboard focus is on the tab control for tab 1.

I’d been assuming result #1, but the screenshot looks maybe like #2.

Do you see a difference between navigating to a previous tab using the CTRL-A shortcut vs pressing CTRL-Q, typing a tab name and then pressing enter to switch to it via the popup menu? They should be the same, but the two flows have slightly different code paths.

The issue I described is the first case.
Using Ctrl+A to navigate to a previous tab has no such issue.

---

I tested QuicKey on another two Mac notebook. One of them has the same problem of mine, the other one also has problem -- focus goes to the address bar.

I did some more tests and found that switching between tabs in one window will cause the bug and switching to a tab in another window is ok.

I'm not familiar with programming Chrome extensions, but I'd like to have a try :)

[fwextensions]

Thanks for the further testing. Which versions of macOS are on those laptops? My bet is that something changed in a more recent version of macOS that causes the focus to change when you focus an already focused window. That sounds like either a bug in macOS or Chrome (most likely, Chrome hasn't caught up to this new behavior).

Using Ctrl+A to navigate to a previous tab has no such issue.

Interesting. Possibly this is due to focusing an already focused window while the popup menu is open, since that's not open when using the CTRL-A shortcut.

Anyway, I think I have a workaround for this, so I'll create a new build and let you know how to test it. Might take a few days.

[haokuixi]

Hi @fwextensions I simply changed the order of window focusing and tab activating and it worked as expected. I created a pull request and you can take a review.

[haokuixi]

I just found that it works in that way, but I don't know why. After changed the updating order, I tried activating the tab, but not focusing the window and the bug appeared again. After some more testing I found that in order to avoid the bug, focusing window is essential and must be done before activating the tab.
It is inferred that the if statement around updating window is always true. I tried to log some debug info, but failed -- console.log did not work in app.js.

setInterval(function() { console.log(chrome.windows.WINDOW_ID_CURRENT); }, 1000);

No matter which window I am in, running above code in the background.html will always produce -2. I don't know if this is the right way, but the results are in line with expectations.
The conclusion is that, we can always focus the window and then activate the selected tab, without extra logic judgement.

[fwextensions]

Thanks for the PR! I added a comment.

Yeah, WINDOW_ID_CURRENT is an enum that's always -2, while I'd assumed it was actually the ID of the current window. So that if branch was always true (the tab's window ID is never -2) and the window was always getting focused after the tab was activated. Sounds like you found that just changing the order fixes it.

To see the console output from the popup, you have to right-click in the popup and open devtools from there. Then you'll see the log calls from the popup code. That devtools window will get closed when the menu closes. It's a bit of a pain, so I also set up a log() global function that outputs to the background page's console.

[haokuixi]

I agree with your comment. Changing the order did solve the issue. It feels much better to use QuicKey now😄

[garyking]

Is this issue still waiting on #7 to be closed? I'm still experiencing the initial described issue.

[garyking]

Also, a minor note, but the first tab does not get focused if the current tab is a "new tab" before I choose a tab to switch to.

Steps:

1. Open a new tab in Chrome.
2. Use this ext to switch to another tab.
3. First tab does not get selected.

Not sure how important this detail is though.

[fwextensions]

I've pushed a new version that I think fixes this issue here: https://github.com/fwextensions/QuicKey/releases/download/v1.1.1/QuicKey.zip

You can download that zip and load the extension locally if you'd like to test it. Let me know if you'd like instructions on running local extensions.

[garyking]

Will the update be pushed to the Chrome store? I'd prefer just getting it that way.

[fwextensions]

Yes, I'll push it to the store, but wanted to test it for a bit first. The Chrome store version will update automatically.

[fwextensions]

I did some more tests and found that switching between tabs in one window will cause the bug and switching to a tab in another window is ok.

Interestingly, I recreated something like this on Windows when updating the code. In the background page, which handles the tab navigation via the hotkeys, the tab and window were focused using the promisified API, while the popup was calling the chrome APIs directly. I changed the popup to focus the window first with the promise API and then in that call's .then(), I accidentally left the direct call to the chrome.tabs.update() API. With that flow, switching tabs within the same window didn't work at all (or at least, didn't visibly change the active tab), but switching tabs that were in different windows did work. When I changed the call for activating the tab to use the promisified API, everything worked again.

So there does seem to be some subtle timing issues with focusing tabs and windows that I'd never run into before, and which I think became more apparent with new versions of macOS.

[fwextensions]

@haokuixi, have you been able to try out this branch?
https://github.com/fwextensions/QuicKey/tree/bug/mac-focus-issue

The window is focused first, like in your PR, but the tab isn't focused until the window focus promise returns, which is how it works in the background page. So it should fix the issue, as you weren't seeing it when using the previous tab keyboard shortcut.

[fwextensions]

I've published v1.1.1 to the webstore, which should fix this issue. Please let me know if you still see it after the extension updates.

[garyking]

It works great. 👍

[fwextensions]

Thanks for confirming.