Closed Bug 1484030 Opened 2 years ago Closed 2 years ago
Chiclet animation for CFR
We would like to have an animation for the chiclet in the awesomebar when the CFR message is activated; see attached invision for details
Actually triggering the animation and managing responding to page changes etc. is not in the scope of this, and will be covered instead by Bug 1484034. However, you can test the ui element with the instructions in the comment here https://phabricator.services.mozilla.com/D3804. Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=94bf5b750af1a86c553d909298fa1fc769e012c2.
Adam and I had a brief conversation about attachment 9002519 [details]. The animation of the width property on #cfr-label presents a performance problem - it will trigger a reflow each frame and likely jank. We discussed possibly using a transform: translateX for the contents while leaving the container a fixed width. However, that leaves an open question on how to move the faded "edge" that truncates the urlbar with the animation.
Here is a recording of the animation from the current patch, obtained by animating the width of the element. You can see that as the cfr ui element expands, the url bar text input to the left shrinks in width and in particular the faded-out right-hand edge moves leftwards. Gijs do you have any suggestions about what to do about the right-hand faded edge of the url bar text if we use Sam's workaround of a fixed-width container and transform: translateX?
(In reply to Adam Hillier :ahillier from comment #4) > Created attachment 9003020 [details] > cfr-ui-animation.mov > > Here is a recording of the animation from the current patch, obtained by > animating the width of the element. You can see that as the cfr ui element > expands, the url bar text input to the left shrinks in width and in > particular the faded-out right-hand edge moves leftwards. > > Gijs do you have any suggestions about what to do about the right-hand faded > edge of the url bar text if we use Sam's workaround of a fixed-width > container and transform: translateX? If we don't want to actually change the width of the URL bar, I think you could change or move the fade. Specifically, that fade is set using a mask-image, here: https://searchfox.org/mozilla-central/rev/3fa761ade83ed0b8ab463acb057c2cf0b104689e/browser/base/content/browser.css#595-598 You could set an attribute on the URL bar while you're animating (possibly there instead of on the item (chiclet is a weird word for this!) itself), that triggers both the animation and a different mask. The mask seems to be multiplied with the foreground, and is "to the left" (I found this confusing when I first looked at it, so I'm spelling it out). "Transparent" means text ends up transparent (so you see the url bar background), "black" means you get text. It seems to me that, given you know the width to which you're animating (I assume, in order to make the extant patch work), you can basically modify the gradient by adding a stop, from: mask-image: linear-gradient(to left, transparent, black 3ch); to something like: mask-image: linear-gradient(to left, transparent, transparent <width-of-item>, black calc(<width-of-item> + 3ch)); Then the fade-out would move while the item animates in, with a bit of whitespace where the 'recommendation' bit is merging in. This would only really look OK if the animating-in was quick enough (ie more like 300ms or something instead of the 2s in the video, which I assume is artificially slowed down). Does that sound workable? The other option here is that it actually seems like `mask-position` is an animatable CSS property. So if you use an attribute on the urlbar to trigger the transition in the thing you're doing, you can presumably trigger another transition (of the same length, at the same time) of the mask-position from 0 to `-<item-length>`. It *looks* like that should work, though you'll want to make sure you get the math right (possibly with a subtly different gradient that leaves a bit more fully-blank space at the end of the URL bar) or you'll get slivers of text appearing between the mask (which is moving) and the transitioning text.
Attachment #9003020 - Attachment is obsolete: true
Comment on attachment 9002519 [details] Bug 1484030 - Implement chiclet animation for CFR :Gijs (he/him) has approved the revision.
Comment on attachment 9002519 [details] Bug 1484030 - Implement chiclet animation for CFR Kate Hudson :k88hudson has approved the revision.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/17ffad06d94f Implement chiclet animation for CFR r=Gijs,k88hudson
Backed out for failing bc at browser/base/content/test/performance/browser_tabopen.js Push that contains the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=bbbab4206c4696bf21ae5e8b93f06bd38dd015b3 Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=195786732&repo=autoland&lineNumber=1969 Backout: https://hg.mozilla.org/integration/autoland/rev/9f0c56001fbffc0afe2eabffeb7b65b7139d56cd
Backout by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/0ccf5da4244e Backed out changeset 17ffad06d94f for failing bc at browser/base/content/test/performance/browser_tabopen.js on a CLOSED TREE
The try push linked here seems to be for a different bug, was it really this patch causing the failure? It seems unlikely given that this only adds a hidden element
Hi Kate. What try push are you referring to? Retriggers for the failure ended up on the push for this bug: https://hg.mozilla.org/integration/autoland/rev/17ffad06d94f The push in the backout comment, is just a push that contains the failures. However, since retriggers reran on the push for this bug, here are the results: https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=success&filter-resultStatus=pending&filter-resultStatus=running&fromchange=4a333f450838fbc7dd58146696e2ec9a11e84bdf&filter-searchStr=OS%20X%2010.10%20opt%20Mochitests%20with%20e10s%20test-macosx64%2Fopt-mochitest-browser-chrome-e10s-7%20M-e10s(bc7)&tochange=f84d024c27b5e8b12aecb986218eac2b5aa2f703 Let me know if i can provide any other info.
Ok thanks! We did end up identifying the issue and will be pushing the fix. Thanks!
(In reply to Kate Hudson :k88hudson from comment #14) > Ok thanks! We did end up identifying the issue and will be pushing the fix. > Thanks! you're welcome!
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/2d747f83e537 Implement chiclet animation for CFR r=Gijs,k88hudson
You need to log in before you can comment on or make changes to this bug.