Stealing focus on suspend

[hmnd]

Description:

The Great Suspender appears to make Chrome steal focus when it suspends a tab with Chrome v69.

Specifications:

• Extension version: 6.30
• Browser & version: 69.0.3497.12
• Operating system & version: Arch Linux

[liamjohnston]

Can you be more specific about what happens exactly?

The way you make it sound, you're on tab A and then suddenly get taken to tab B when tab B automatically suspends.

The only time I've seen unexpected tab switching is if a tab tries to auto-suspend but has some sort of unfinished-form alert like this:

(^ which I think is a good thing personally)

Edit: Related gitHub issue for the unfinished-form alert: #272

[hmnd]

What I'm getting is if I'm in an application other than Chrome, when a tab gets suspended, Chrome steals the focus from the other application. It doesn't switch to the suspended tab though.

[hmnd]

I'm currently trying out the Alpha version of the extension and will update, should I find this not happening any longer.

[hmnd]

Just happened for me on Alpha.

[CollinChaffin]

As I had also pointed out in #704 (not sure if those logged errors are related) this is a real problem here as well.

EDIT: To clarify for the author - 100% focus is now forcibly stolen by whatever Chrome window specifically has TGS extension calling for a suspend operation - WHETHER OR NOT IT CALLS FOR ANY USER INPUT. In other words - yes it might be a good thing if it wants to close a form (the above poster must have that option disabled since it should NEVER do that otherwise) but recently even quiet suspend operations now continually bounce Chrome windows to the front to the point of it being VERY obtrusive even to other apps. And as I stated above and in #704 it does seem to coincide with these errors popping up recently so I wasn't sure if it was related.

EDIT#2: It appears that commit yesterday d2e17a7 has rectified the errors I posted in #704!

[hmnd]

@CollinChaffin Just installed extension from source. This behavior continues to occur for me.

[CollinChaffin]

Correct I meant the "undefined" errors in my #704 were rectified with that commit but this modal focus-stealing behavior is now beginning to cause SERIOUS issues on systems I am seeing it literally steal focus and pop up chrome windows with, in some cases, STILL UNSUBMITTED FORMS and because the user was in the process of pressing the ENTER key on their MS-WORD when TGS stole the focus, their enter key literally has posted premature form data! This issue should really be priority #1 right now with as many problems as it is causing.

In fact, I have to quickly add as further example, just as I typed this quick response, TGS has now interrupted me SIX times in a matter of only two minutes popping up three different Chrome windows that has tabs suspending. Does the author use this extension and if so how is this not making him sit and swear out loud too? LOL :)

[hmnd]

Ah I understand. Is this happening for you on stable chrome?

[fwextensions]

Is this maybe only happening on Linux? Never seen it on Windows.

[hmnd]

@fwextensions Switched to Windows for a bit to see. It still happens, except Chrome doesn't steal attention, just requests it. (as in, icon in taskbar flashing orange)

[fwextensions]

Interesting. I don't think I've ever seen a suspended tab request focus in a few years of running TGS on Windows. Could it be interacting with some other extension you're running in both Windows and Linux?

[hmnd]

Still happens with all extensions disabled.

[fwextensions]

Did this just start happening with Chrome 69? I'm still on 67 in Win7, which might be the difference.

[CollinChaffin]

This was Chrome 69 (now 70) DEV on Win7x64 systems. No flashing taskbar but absolute full popup, modal type steal focus from any other window/app. Again, to describe if you have 5 Chrome windows open with 10 tabs each, minimize them all and then at the 15 min mark window 1 will pop open once for the 1st tab to suspend. Re-minimize that window, and go back to another app - a few SECONDS later - rinse and repeat as the next 9 tabs on that window in succession as to being suspended touched last - suspend one by one. Now, rinse and repeat that annoying popup from the non-Chrome app (as a pure example) NINETY-NINE more times (assuming you have all tabs set to be suspendable).

Once you truly experience what I just described you will also consider this an absolute critical issue. And, like I said above get caught hitting enter on another app when just one of the 99 popups in my example occur (which leads me to further explain) that when the first of the ten tabs in Window 1 suspended in my example, mind you that was NOT the active tab in Window 1 that just popped up meaning my caught enter keypress just went into a still ACTIVE tab in Window 1 (lets say sitting on an un-submitted form) and boom - the enter key just inadvertently submitted it. Believe me when I say if you often have dozens of Chrome windows and HUNDREDS of tabs (the primary use for TGS to begin with), it actually is much easier than one would believe to have typing/keypresses being often now sent suddenly into unwanted Chrome windows in v69+ running TGS extension.

[fwextensions]

That's weird, because it sounds like one of the changes in Chrome 69 is to prevent unfocused tabs from stealing focus:

The window.confirm() method no longer activates its parent tab
If a document in a background tab calls window.confirm(), it returns immediately with false, and no dialog is shown to the user. If the tab is active, then the call shows a dialog as normal. Specifically, this removes the ability to use window.confirm() to bring a tab to the front because this is rarely what the user wants.

Perhaps something about how TGS suspends tab is causing a buggy interaction with this new logic in 69.

[xeon927]

Just chiming in to say that this has started happening for me as well.
Chrome 70.0.3514.0-dev
TGS 7.0.73 (loaded from source due to issue with Chrome store version storing cookies and breaking Google sites)

[matznerd]

Hi, on chrome Version 70.0.3521.0 (Official Build) canary (64-bit), I am getting tabs that appear to be ready to be suspended, popping up out of nowhere while I am on other pages. I believe this is the same activity as reported above and I am using the alpha 7.0.85 tgs build.

[fwextensions]

For people on Chrome 69 or 70, do you have the screen capture option on or off? Maybe the rendering of the page to a canvas as the tab is suspended is causing an issue. Perhaps the addition of OffscreenCanvas to 69 had some interaction.

According to this page, 69 will be marked stable in 3 weeks: https://www.chromestatus.com/features/schedule So there's a countdown to Tabbageddon started.

[hmnd]

I have screen capture disabled.

[fwextensions]

Maybe the latest alpha fixes it? https://github.com/deanoemcke/thegreatsuspender/releases/tag/v7.0-beta.94

[deanoemcke]

Can everyone please let me know the operating system they are using?
I cannot replicate on OSX high sierra with chrome v70.0.3514.2.
Have also tried a debian virtual machine with no luck (it think it was on a recent chrome beta build).

[hmnd]

@deanoemcke I have tried on both Windows (Build 17738) on which it only makes the icon flash as opposed to outright grabbing attention, and Arch Linux (which doesn't really have a version, but on the latest Linux kernel). Both are running the latest Chrome Canary build.

[CollinChaffin]

Win7x64 from Chrome 69 up to 70 this has been occurring, either with OR WITHOUT screen capture enabled (but usually I have it disabled on my systems). I cannot find a system for some time that does not exhibit this issue but all my systems have been on late Chrome versions > 69 and I believe all Windows 7 or 10 based and x64. From the comments above thought, it sounds like this may still be occurring with older versions of Chrome as well (but I cannot confirm at this moment),

[fwextensions]

Never seen it on Win7 or Win10 x64 up through Chrome 67, using either the webstore version or an older alpha. Sounds like it started happening in 69, and the focus grabbing is more aggressive in Win7 and Linux, while Win10 is more polite, but still annoying.

[fwextensions]

FWIW, I installed Chrome 70 on a Win10 machine (without admin privileges, if that matters), added the webstore version of TGS, set it to suspend after a minute, opened several tabs in a couple of windows, and I'm not seeing any focus issues when the tabs suspend.

Could be some other extension's content script reacting to the tab getting suspended? Or maybe a Chrome flag that was set at some point in the past?

[deanoemcke]

@hmnd @CollinChaffin @xeon927 @matznerd can one (or more) of you please send me a screenshot of what this looks like? ie: what does the chrome window look like when it steals focus?

and to further clarify the exact steps to reproduce here:

1. set time to suspend to 20 seconds
2. open a new tab to google.com
3. open a second tab (to lose focus on the google.com tab)
4. open a different application on the operating system (to lose focus on the chrome app)
5. wait 20 seconds for google.com tab to suspend
6. chrome application gains focus and pops something up on the screen?? (or just flashes in the taskbar in the case of windows).

[hmnd]

@deanoemcke In step 6, it pops up the window that contains the suspended tab on screen, with no unusual indicators.

[deanoemcke]

@hmnd and to confirm, when you have this happen on windows (albeit just the icon flashing), it's with windows 10 and chrome canary v70.0.3525.0 ?
This is exactly my test scenario and I cannot reproduce :(

and have you tried with a different chrome profile? what if you create a new profile and only install this one extension (that being the dev build of TGS).

[hmnd]

@deanoemcke Testing on Linux, it looks like instead of bringing the window to the foreground, the window only gains focus if it's minimized when a tab is suspended. This does not appear to occur anymore when the Chrome window is not minimized. I'm running KDE and the only indication I have that Chrome gains focus is that the menu bar switches to Chrome's options. This occurs regardless of what other extensions I have installed (I tried with a different Chrome profile just now).

---

By menu bar, I mean this:

[hmnd]

@deanoemcke Also, to answer your question, yes it's latest Insider Build of Windows 10 on latest Chrome Canary.

[fwextensions]

Could this be related to #646, which @CollinChaffin was seeing but @deanoemcke wasn't able to reproduce? Perhaps it's due to some experimental flag that some users set at some point, or was set by an earlier dev build, and is now stuck in a state that's different from what you'd get in a fresh install of the dev channel.

If you open chrome://flags and then open devtools, running this code should dump out all the flags set to non-default values:

returnExperimentalFeatures = (data) => { 
    let changed = data.supportedFeatures.filter(feature => !feature.is_default); 
    changed.forEach(feature => { 
        let option = feature.options.filter(opt => opt.selected)[0]; 
        console.log(feature.name, option.description); 
    });  
};
requestExperimentalFeaturesData()

Might be a clue there.

[CollinChaffin]

@fwextensions That code throws errors on Chrome v70:

Uncaught TypeError: Cannot read property 'filter' of undefined
    at changed.forEach.feature (<anonymous>:4:38)
    at Array.forEach (<anonymous>)
    at returnExperimentalFeatures (<anonymous>:3:13)
    at <anonymous>:1:1

I did figure out a way to dump them all but it's a bit ugly and am just working on cleaning up the code to filter out only the non-default values. If you come up with a way first go ahead and post it and I'll use it. I do have some flags set none that I can think of that would ever PROMOTE (more than default) the ability for anything to command window focus. Again, this is on multiple Win7 systems and I cannot actually produce one using current Chrome DEV v70 that does not exhibit this very problematic behavior. If it turns out to be a flag I will certainly jump for joy but I also have not changed any flags since this issue began so I will frankly be a bit surprised it if is.

[fwextensions]

I guess the flag data has changed in 70? I don't have access to a system with 70 right now. This code should at least handle flags that don't have an options array so that it won't throw:

returnExperimentalFeatures = (data) => { 
    let changed = data.supportedFeatures.filter(feature => !feature.is_default); 
    changed.forEach(feature => {
		let options = feature.options; 
        let option = options && options.filter(opt => opt.selected)[0] || { description: "unknown value" }; 
        console.log(feature.name, option.description); 
    });  
};
requestExperimentalFeaturesData()

Agree that it's probably unlikely that this bug is due to weird flags, unless those get synched across installs based on the signed-in Chrome user.

[fwextensions]

I think I may have seen this behavior in 68 when loading the extension from the master branch. It started suspending discarded tabs, and it seemed like sometimes that made the tab come forward. It was a little hard to tell, as my machine became nearly unresponsive, as described here #723 (comment), so it may have been very delayed responses to clicks. But I definitely hadn't seen anything like that in extension versions up through 7.0.72.

[hmnd]

@fwextensions @deanoemcke This is still happening on Chrome 70.0.3538.77 on LInux. Not terribly intrusive, but still annoying. Global Menu keeps switching to Chrome every time a tab is suspended which means that the extension is still getting Chrome to grab attention somehow. Let me know if there's anything I can provide you with to help resolve this.

[deanoemcke]

I guess this is a duplicate of: #865 ?
Should be resolved now.

[ahaq0]

Still have the exact same issue

[dijitul]

I am getting this on latest chrome.

SO annoying.

[hmnd]

@dijitul see #865 (comment)

[dijitul]

Thank you @hmnd - sorted! :)