Created attachment 8742616 [details] Screenshot of the problem User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160413135321 Steps to reproduce: 1. Trigger a download 2. Wait for the animation to finish Actual results: When the arrow animation completes, the last frame is left drawn on the toolbars until something else forces a redraw. (Which takes forever on composited desktops like mine, since there's no longer a need for Firefox itself to redraw after an XDamage event like covering and uncovering the window. Normally, I just get fed up and use KWin's "toggle compositing" keyboard shortcut twice in order to force a redraw.) Expected results: The remnants of the final frame of the animation should have been cleaned up the instant the animation finished.
Do you see the same issue with FF45? If not, could you find a regression range with Mozegression, please. http://mozilla.github.io/mozregression/
At the moment, I'm pressed for time with the deadline for my degree project looming, so testing another Firefox version is a bit hard to schedule, but I'll leave the needinfo request in my inbox and get to it as soon as possible. (First week of May should be the absolute latest.)
Hiro, I think this is a duplicate of another bug but I can't find it. Do you remember the other bug about not painting the last frame of the download animation?
That's bug 1204336, I think. The reporter of bug 1204336 said bug 1204336 has been fixed by the patch for bug 1161978. But I think this issue is different from that bug because I saw this in this April on my linux box.
I succeeded to reproduce this issue on today's nightly.
Status: UNCONFIRMED → NEW
Ever confirmed: true
After watching attachment 8742616 [details] carefully, I noticed that there are two remaining images. I guess one is the last animation frame. The other one must be an intermediate frame. So this issue is completely different from bug 1204336. Actually I can see only the intermediate image on my linux box.
I can't reproduce on Windows. Marking this as Linux-only.
Keywords: regression, regressionwindow-wanted
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Hi Stephan, I have tested your issue on latest FF release (46.0) and latest Nightly build and could not reproduce it. I have downloaded images, pages and files, but I haven't encountered any issues as seen in your screen shot. I've tested this on Windows 7 x32 and Ubuntu 14.04 x64, on the latest release(46.0), latest Aurora(47.0a2) and latest Nightly(49.0a1). Is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E). Thanks, Paul.
Created attachment 8746515 [details] Newer screenshot My aurora 47.0a2 (2016-04-13) currently looks like this. Anything beyond that will have to wait until May because I'm too busy with my degree project right now.
46b and stable is a-ok, started getting this with 47b1. Is that narrow enough?
(In reply to Rémi Cardona from comment #10) > 46b and stable is a-ok, started getting this with 47b1. Is that narrow > enough? Not enough, could you run Mozregression and copy here the final pushlog with the last good build and the first bad build: http://mozilla.github.io/mozregression/ You can run the command "mozregression --good=46".
I'm having issues with mozregression. It only downloads builds where the animation is either correct, or the "download is finished" animation is completely different (a red dot/block) on newer alphas. So I'm a bit at a loss here.
Created attachment 8748092 [details] another screenshot On my profile, I've removed the download button from the main bar, so it's the blue download animation happens around the hamburger icon, and the misrendering is even more visible in this case.
You can create a custom profile (just for testing) with your own settings for the toolbar and use it with mozregression. So it's more easy to reproduce the issue when the nightly starts.
It's the command --profile=\path_to_profile --profile-persistence=reuse
It's not a profile issue (though I'll keep your tip in mind next time). It's just that mozregression won't download versions of firefox that are (I think) close to the one I have (47b1). 48 and up seem to have a completely different animation. 46 and below don't have the bug. Bottom line, there's nothing for mozregression to bisect.
What are the next steps for this bug? Does it need a regression range? Does it need to be assigned to someone on a specific team? It's not clear to me where the bug is exactly.
I think we need the regression range to track this down by someone who can reproduce this issue easily. That's because it's really hard to reproduce this issue to me locally. I can reproduce it locally but it seems to depend on browser's uptime or some sort of it. So I can't reproduce it by mozregression at all.
I guess we are stuck here until someone can reproduce better.
I've been checking this on every nightly everyday in these days. And now I am guessing this issue might have been fixed recently because I've never seen the issue for a week or so. As far as I remember, the last time I saw the problem is in the middle of the first week of this May.
Today I've been using each nightly from 1th May one by one, and check it over and over. And I am now inclined to conclude this bug has fixed in nightly on 5/9. Whole relevant change sets are here: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bae525a694e2dc0aa433885be8751330d4995a49&tochange=043082cb7bd8490c60815f67fbd1f33323ad7663 I think Markus' change fixed this issue. https://hg.mozilla.org/mozilla-central/rev/88281a61cde8 Markus, is there any chance that changeset fixed this bug?
Hmm, unlikely. I don't think we ever pull up solid background colors into transparent layers in the browser chrome. Certainly not into the downloads arrow layer, because the chrome under the arrow is a lot more complicated than just a solid opaque color.
Thank you, Markus. I will try to track down which change actually fixed this bug from now on.
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8fa8077e9c5f8610cf55f084930b8650b3710b1f&tochange=246fdb220ef355bffd166aee2d53e8fbff5dfa56 What a surprise! https://hg.mozilla.org/integration/mozilla-inbound/rev/05cb31c61bf2 This particular change fixed this bug. I did check that backing this change out on current trunk does cause this bug again, just in case. Timothy, do you think we still need the regression range? One thing I am concerned is that this change set does not have any test cases for this bug. The change set has actually test cases, but it's for bug 1258904, not for this bug. And I have no idea how to write the test case because I have no reliable way to reproduce this issue yet.
If we have a fix and know which versions are affected then we can probably get by without a regression range.
Closing because this bug has been fixed by a patch for bug 1258904.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox46: --- → unaffected
status-firefox47: --- → wontfix
status-firefox48: --- → wontfix
status-firefox49: --- → fixed
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.