Extend the pause in the download-complete button before transitioning back to the download icon
Categories
(Firefox :: Theme, enhancement, P2)
Tracking
()
People
(Reporter: sfoster, Assigned: jaws)
References
(Blocks 1 open bug)
Details
(Whiteboard: [proton-icons] [priority:2a] [proton-uplift])
Attachments
(1 file)
|
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
When a download finishes, we animate a transition from the progress circle shape to a checkmark, and finally back to the download icon. UX has requested we extend the time the checkmark is visible in this animation.
Updated•4 years ago
|
| Reporter | ||
Comment 1•4 years ago
|
||
The svg image in question: https://searchfox.org/mozilla-central/source/browser/themes/shared/downloads/notification-finish-animation.svg already has some duplicated frames in the middle which give us the existing "pause" in between transitions.
:mstange, one way to do this is to insert a bunch of extra frames in the filmstrip SVG. But IIRC there is a size threshold on these images, beyond which it won't give us the performance characteristics we want. Can you point me at those details? Adding the frames necessary here to get the timing right results in a 2520x20 image.
The other option is to either split the animation up into a couple of phases, insert an animation-delay and chain them together with animationend - I'd rather avoid that if possible as its more logic to maintain to accomplish what should be an atomic thing. Or, to figure out the keyframes necessary to pause at some % which corresponds to a particular frame in the film-strip. That seems doable but I'm not sure of the accuracy or potential for rounding errors which would throw the whole effect off.
Updated•4 years ago
|
| Assignee | ||
Updated•4 years ago
|
Comment 2•4 years ago
|
||
(In reply to Sam Foster [:sfoster] (he/him) from comment #1)
:mstange, one way to do this is to insert a bunch of extra frames in the filmstrip SVG. But IIRC there is a size threshold on these images, beyond which it won't give us the performance characteristics we want.
Ah, right, there is a "prerender size" restriction. The limit is 1.125 times the size of the window, or 4096 pixels, whichever is smaller.
Adding the frames necessary here to get the timing right results in a 2520x20 image.
I think it's better to avoid duplicate frames, even if it requires some custom adaptation of the CSS code.
The other option is to either split the animation up into a couple of phases, insert an animation-delay and chain them together with animationend - I'd rather avoid that if possible as its more logic to maintain to accomplish what should be an atomic thing.
I agree, having to use JS to coordinate the animation seems annoying.
Or, to figure out the keyframes necessary to pause at some % which corresponds to a particular frame in the film-strip. That seems doable but I'm not sure of the accuracy or potential for rounding errors which would throw the whole effect off.
I think that should work fine. For each animated sub-phase of the animation, it looks like the @keyframes frame needs to set the number of steps for that phase, using animation-timing-function: steps(n);, like in this example: https://codepen.io/mstange/pen/dyvyXxM
And the percentages for the keyframes need to be based on the total duration of the animation, including pauses.
As for rounding errors, I'm not completely sure... I think what could happen, if the percentage accuracy is not high enough, is that each animated phase could end up with a frame rate that's slightly different from 60Hz, maybe 59Hz or 61Hz, so in theory a frame could be skipped or duplicated. But I don't think there's a way to get partially-drawn or clipped or offset icons through inaccuracy, as long as steps(...) is used with the right number. So I think it should be fine.
| Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Comment 5•4 years ago
|
||
| bugherder | ||
Comment 6•4 years ago
|
||
Can we please uplift to Beta 89?
Comment 7•4 years ago
|
||
Comment on attachment 9220446 [details]
Bug 1709173 - Extend the checkmark phase of the download-finish animation by 100 frames.
Beta/Release Uplift Approval Request
- User impact if declined: The checkmark for the download disappears quickly
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: Complete a download such that the download finished animation shows. There should be a visible difference in how long the checkmark persists after a download completes (before reverting back to the arrow-with-a-tray icon)
- List of other uplifts needed: Bug 1709172
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): There is some fiddling with the animation CSS and image, and a tiny JS change - but nothing can really break catastrophically from this changeset (well, I don't think so anyway...). It applies cleanly to beta.
(Note: I don't think uplifting bug 1709172 is strictly required for this, but they touch some of the same files so it seems more straightforward to uplift both.)
- String changes made/needed: Nope
Updated•4 years ago
|
Updated•4 years ago
|
Comment 8•4 years ago
|
||
Comment on attachment 9220446 [details]
Bug 1709173 - Extend the checkmark phase of the download-finish animation by 100 frames.
Approved for 89 beta 15, thanks.
Comment 9•4 years ago
|
||
| bugherder uplift | ||
Updated•4 years ago
|
Reproduced the issue on affected Nightly 90.0a1 '05-03-2021' on Windows 10, Mac OS, Ubuntu 20.04.
Verified fixed on the latest Nightly 90.0a1 '05-20-2021' on the above mentioned OS-es.
Waiting for the fix to land in Beta 89.0b15 to verify further.
Verified fixed on the latest Beta 89.0b15 on the above mentioned Os-es.
Description
•