Remove the leading fire from the taskbar progress handler#19403
Merged
Conversation
If the progress state hasn't been set for more than 200ms, we shouldn't even bother flickering the old state. Closes #13934
lhecker
approved these changes
Oct 2, 2025
DHowett
added a commit
that referenced
this pull request
Oct 8, 2025
If the progress state hasn't been set for more than 200ms, we shouldn't even bother flickering the old state. This prevents applications from making the tab (and the taskbar icon) flicker. We were reviewing #19394 and decided that the _original_ behavior before Leonard's throttling fix was somewhat unfortunate as well. An application that sets an indeterminate state for 10ms and then clears it shouldn't be able to make any part of the application flicker, fast _or_ slow. Removing the leading fire time from the throttled function ensures that it will only fire once every 200ms, and only with the state most recently set. It will not debounce (so setting the progress every 150ms will not prevent it from updating.) Closes #19394 (cherry picked from commit 998ab58) Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgfZOsM PVTI_lADOAF3p4s4Axadtzgfb1Nw Service-Version: 1.23
DHowett
added a commit
that referenced
this pull request
Oct 8, 2025
If the progress state hasn't been set for more than 200ms, we shouldn't even bother flickering the old state. This prevents applications from making the tab (and the taskbar icon) flicker. We were reviewing #19394 and decided that the _original_ behavior before Leonard's throttling fix was somewhat unfortunate as well. An application that sets an indeterminate state for 10ms and then clears it shouldn't be able to make any part of the application flicker, fast _or_ slow. Removing the leading fire time from the throttled function ensures that it will only fire once every 200ms, and only with the state most recently set. It will not debounce (so setting the progress every 150ms will not prevent it from updating.) Closes #19394 (cherry picked from commit 998ab58) Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgfZOsU PVTI_lADOAF3p4s4BBcTlzgfb1NE Service-Version: 1.24
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If the progress state hasn't been set for more than 200ms, we shouldn't even bother flickering the old state.
This prevents applications from making the tab (and the taskbar icon) flicker.
We were reviewing #19394 and decided that the original behavior before Leonard's throttling fix was somewhat unfortunate as well. An application that sets an indeterminate state for 10ms and then clears it shouldn't be able to make any part of the application flicker, fast or slow.
Removing the leading fire time from the throttled function ensures that it will only fire once every 200ms, and only with the state most recently set. It will not debounce (so setting the progress every 150ms will not prevent it from updating.)
Closes #19394