-
Notifications
You must be signed in to change notification settings - Fork 29.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not hide notifications without prompt when window has no focus #80285
Comments
(Experimental duplicate detection) |
Actually that should be the case given this line:
Can you demonstrate where this does not work? A notification should not start to hide automatically if the window does not have focus. |
Thanks for having a look @bpasero ! That line might save us if the notification were sticky or prompting. For for stuff like what I'm talking about, you wouldn't want a notification to be that heavyweight - you'd just want it to tell you what it's got to tell you and disappear. For example, you go to a meeting and come back to your desk and re-open VSCode - you want that notification that the branch head moved half an hour ago to appear, get its 15 seconds of screen-time, and disappear. To be sure I'm clear, here are some repro-steps:
|
Got it. It looks like we did an explicit decision (in 29ab698) to only keep notifications around that ask the user for input, even if the window does not have focus. I think we can leave this open as feature request, but I am not sure if we want to change this in the near term. We are sensitive to not showing too many notifications at once. For that purpose we have the notification center to always access notifications as needed. |
I'm not sure I buy that. We used notifications as a way to inform people of available updates to our extension for a while. I believe we made the correct decision to only inform people, and not, say, add a button to require interaction. It's just an update, the user can make their own decision about it. We just wanted 15-seconds of face-time with the end-user to tell them the option was available to them. Our telemetry showed that we didn't get that 15-seconds. Most of the time when a new update was detected, VSCode wasn't visible and thus the user never saw it. The idea that users can go sniffing in the notifications window to find notifications they missed is a non-starter. Sorry, users just never do it. They open the notification panel when they say "Hey wait, I saw a notification about that a minute ago!" and that's the only time they do it. Likewise, for the scenarios I mention, a push to the user's branch, a new pull request to review, etc. Are all things that the user just needs to be informed of and shouldn't demand anything more than a glance. Hence, we haven't put any buttons. The behavior it does now when the app is open is perfect - it shows it, the user can read it or not, act on it or not, and in any case it's gone in 15 seconds, is really what we want. But if the app isn't open, I might as well not even bother to pop the notification, because I can know for a certainty it'll not get read. So, I'm an extension author. What would you have me do?
I'm leaning towards number 2 there, and I hope you can imagine why. You're encouraging extension developers to do stuff that defeats what you were trying to achieve by the code change you reference. I dare say if anything, the code change made the problem worse because it encourages extension developers to do the wrong thing. Notifications aren't fundamentally bad - but it's certainly the case that over-eager extension developers can make them bad. I respect that you're trying to put up some rails here to ensure that bad extensions don't make VSCode look bad, but there's a limit to what you can do here. It really needs to be up to the extension to behave well here. |
Fair enough. I have pushed a change to treat all notifications equally and not hide them if the window does not have focus. I appreciate your concern that extensions should not trick our system by adding buttons and I fully agree on that. I still think we have a fair amount of work to do to allow users to control notifications more fine grained, especially allow them to disable certain notifications from extensions. |
The more I think about it, the more I feel it would be better to keep notifications around only when the window is not visible to the user. I fear Electron does not provide this API, thus filed electron/electron#20145 |
Issue Type: Bug
If an extension posts a notification while VSCode is, say, minimized, the user has to actively search for the notification in order to see it.
While the 15-second timer on notifications is generally a good thing, the 15 seconds should only tick while VSCode is in-focus.
Here are some examples of cases where notifications might pop up while VSCode is not focused:
VS Code version: Code 1.37.1 (f06011a, 2019-08-15T16:17:55.855Z)
OS version: Windows_NT x64 10.0.18975
System Info
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_deferred_display_list: disabled_off
skia_renderer: disabled_off
surface_synchronization: enabled_on
video_decode: enabled
viz_display_compositor: disabled_off
webgl: enabled
webgl2: enabled
Extensions (4)
The text was updated successfully, but these errors were encountered: