Currently, as of 4/28/23, when starting & stopping a playsolo session, studio will repeatedly trigger a windows task-bar notification, even if the studio window was already focused on beforehand.
Here’s a video of the problem occurring. Observe that even though studio was quickly focused on then un-focused, it continues to trigger the windows task-bar. This is pretty annoying when you are trying to quickly navigate windows & transfer data between programs via the clipboard.
Expected behavior
It is expected that studio would only display a notification once (ideally, not at all).
And this is regardless of the project you have open? I was just trying to reproduce myself and couldn’t get it to happen… I had an empty baseplate with a Script printing to the output to emulate as much as possible
Yep! This happens with any instance of studio that is open. Some things worth noting:
I use alt + tab to switch windows
My taskbar is docked at the top, and it’s configured to autohide
I use the “virtual desktops” feature of windows 10. I have multiple application windows spread across multiple virtual desktops. I cycle between these desktops via ctrl + win + arrow keys. (this is no longer relevant, see post below)
Just an update - I tried reproducing this issue on a different machine with a “vanilla” studio install (default widget layout, no plugins, different account, etc). I was able to reproduce the issue with that configuration. I was also able to reproduce without virtual desktops being used, so that’s ruled out as being a cause.
Another thing worth noting, I’m running Windows 10 (not 11). It’s possible this is an issue specific to Windows 10 if you are having trouble reproducing on Windows 11.
My story goes like this: I’m testing using F5, in which I would run my playtest and then hit Stop to go back to normal studio. The delay that happens from stopping the test is long enough for me to switch over to discord and message some colleagues there.
Once Studio is in its normal state, it then flashes the taskbar at me. Pressing the windows key twice typically moves the taskbar away, but it then reappears with Studio flashing yellow.
So in a nutshell, I’m in another application waiting for studio to go back to normal from a playtest, only for the taskbar to pop up even after I silence it with the windows key.
How similar is your set up to @Noble_Draconian? Are you also on Windows 10, similar taskbar config?
I did check with the team at the time and there’s nothing we are doing specific with taskbar notifications. One theory is that we do request focus to the 3D View when Play is started… this is to ensure people don’t have to click into the 3D View to engage/play. Then when Stop is activated, we attempt to set focus back to the appropriate panel (eg. a script tab). But there are numerous areas where focus is set.
But even with that on my Windows 11 PC, the Studio icon will flash but it won’t fully switch over out of VSCode (just to confirm: that’s the problem, right?)
I just tried again with maximized windows and auto hide taskbar with no different result.
The problem is that it engages the “flash” notification on the task-bar, which can be annoying if you are using an auto-hide task bar, because the task bar will sometimes steal focus away from your currently focused window.
Roblox studio itself does not steal focus, rather it begins flashing on the task bar (which then sometimes steals focus), and will not stop flashing until you click on it. If you do click on it, it will sometimes continue flashing anyways!
If there isn’t going to be a fix for this in the coming future, would it be possible to allow us to disable studio task bar flashing via some studio setting?
OK thanks for clarifying. I’ll check with the team again now that I have a bit more info. In Windows 11, I can disable the app icon flashing under taskbar settings. I’m still digging around to see how this might be done on Windows 10.
The only other thing I can think of is maybe creating a “Focus Viewport on Play” setting that could be disabled. But that’s just me thinking out loud without an engineer to kick me and tell me how that won’t work
In the original post in this thread, I’ve attached a video of the problem occuring. Notice how at 0:04 I go to interact with the top bar in vscode, and instead I get blocked by the taskbar popping up.
Ideally I wouldn’t have to disable this setting at the windows-level, Roblox studio is the only program I’ve had this issue with.
It can be hard to track mouse and where clicks are occurring in a non-voiced over video, so I apologize.
Most apps don’t have a reason to request focus frequently like we do (outside of keyboard navigation, in which case the main window has focus already). Our whole window layout changes when switching between Play and Edit, most creators prefer that the focus appropriately/automatically shifts for them. In case I wasn’t clear: there’s is nothing in our code that’s saying “flash the taskbar” or sending a notification like something like a chat app might do.
Out of curiosity: why aren’t you upgraded to Windows 11?
Oh, no worries! I wasn’t intending my reply to seem annoyed or anything.
I have various gripes with the OS:
Buggy GPU drivers when I tried gaming on it
Cannot customize taskbar location, file explorer context menu is hidden away behind a sub menu called “advanced”, “combine” was taken away and many other UI gripes
Main computer does not meet the hardware requirements according to the upgrade utility microsoft provides
Got it, thanks! Yeah with the docking corruption (permanent fix coming very soon BTW) we see a significant correlation with certain builds of Windows 10 which had me wondering all the reasons folks stick with it.
I had a thought over the weekend that maybe there’s a way for components to request focus that doesn’t cause the main window to request focus (still assuming that’s what is causing the taskbar flashing). I’m going to keep sniffing around and bothering devs about it… but no promises for a resolution yet.
Apologies in advance if there’s a bug report that encompasses this one, but from my research it seems that this bug report by @Noble_Draconian is the closest match.
I hope it’s okay that I’ve included the issue here as I didn’t want to spam Roblox with a new, but related report.
Let me know if you’d prefer a separate bug report for your issue tracker.
1. Issue
1.1. Summary
Roblox Studio repeatedly tries to take window focus when launching the application:
Always occurs on application launch
The number of times it attempts to steal focus is consistent - it always takes focus exactly 3 times, as seen in the attached video
1.2. Background & Environment
Which OS and version?
Microsoft Windows 10 Pro, Version 10.0.19045 Build 19045
Why not Windows 11?
Encountered several frustrating issues in relation to the OS itself, and within programs I use on a daily basis for work; will consider it once it’s stable
Which Roblox Studio version?
Roblox Studio Version 0.609.0.6090385 - this has been present for a while though
1.3. Reproduction steps
Launch Roblox Studio
Focus another application, e.g.alt + tab
Attempt to continue doing your other task and observe Roblox Studio take focus repeatedly
1.4. Demonstration
2. Desired behaviour
2.1. Consequences
My biggest gripe is with the focus being taken more than once, which often results in Roblox Studio consuming my keyboard inputs whilst I’m working in another application - this has often had undesirable consequences, e.g. loss of work or Roblox Studio processing and executing commands that wasn’t meant for it.
2.2. Expectation
I would prefer if it didn’t steal focus at all. However, based on the behaviour of other applications, I would understand that Roblox would likely want to take focus at least once during the launch process.
2.2.1. Preferred solution
Since Roblox has a launcher splash screen that has already requested focus, I would probably prefer the following behaviour:
The application could first check if the launcher HWND is the active window / has focus
Then, dependent on whether the launcher has focus:
If the launcher has focus → try to set the Roblox Studio application as the active HWND
OR; if the launcher has already lost focus → continue working in the background and don’t claim focus
This would ensure that the application is bubbled to the top if the user is waiting for the application to launch, and would avoid disrupting workflows for others who are continuing to do other tasks outside of Roblox - this seems like it could be the most equitable solution?
