1265605 - Aurora/Developer Edition failing to redraw toolbar after download animation

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Stephan Sokolow]

Attachment: 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.

Comment 1

[Loic]

Do you see the same issue with FF45? If not, could you find a regression range with Mozegression, please.
http://mozilla.github.io/mozregression/

Comment 2

[Stephan Sokolow]

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.)

Comment 3

[Brian Birtles (:birtles)]

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?

Comment 4

[Hiroyuki Ikezoe (:hiro)]

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.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

I succeeded to reproduce this issue on today's nightly.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

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.

Comment 7

[Brian Birtles (:birtles)]

I can't reproduce on Windows. Marking this as Linux-only.

Comment 8

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

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.

Comment 9

[Stephan Sokolow]

Attachment: 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.

Comment 10

[Rémi Cardona]

46b and stable is a-ok, started getting this with 47b1. Is that narrow enough?

Comment 11

[Loic]

(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".

Comment 12

[Rémi Cardona]

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.

Comment 13

[Rémi Cardona]

Attachment: 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.

Comment 14

[Loic]

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.

Comment 15

[Loic]

It's the command --profile=\path_to_profile --profile-persistence=reuse

Comment 16

[Rémi Cardona]

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.

Comment 17

[Timothy Nikkel (:tnikkel)]

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.

Comment 18

[Hiroyuki Ikezoe (:hiro)]

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.

Comment 19

[Timothy Nikkel (:tnikkel)]

I guess we are stuck here until someone can reproduce better.

Comment 20

[Hiroyuki Ikezoe (:hiro)]

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.

Comment 21

[Hiroyuki Ikezoe (:hiro)]

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?

Comment 22

[Markus Stange [:mstange]]

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.

Comment 23

[Hiroyuki Ikezoe (:hiro)]

Thank you, Markus.  I will try to track down which change actually fixed this bug from now on.

Comment 24

[Hiroyuki Ikezoe (:hiro)]

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.

Comment 25

[Timothy Nikkel (:tnikkel)]

If we have a fix and know which versions are affected then we can probably get by without a regression range.

Comment 26

[Hiroyuki Ikezoe (:hiro)]

Closing because this bug has been fixed by a patch for bug 1258904.