In the "Get Add-ons" tab of the extensions manager, the image for the selected addon is shown. While that image is loading, a throbber is shown behind it. However, once the image is loaded, the throbber is never removed -- it keeps throbbing away, causing repaints a few times per second for the region where it would be displayed. The relevant code seems to be here: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/extensions.xml#535 It might not do the behaviour I described on trunk since decks always get native widgets for each child and it's easy to tell that the display is not visible, but once we get rid of native widgets, and in current fennec, it causes the massive repaint issues. I'm not sure if on trunk we'll invalidate (even if we never paint), though; would be good to just get rid of the problem entirely.
Same probem is actually present anywhere where the same approach is used (throbber in a deck), e.g. in the Themes tab.
I assume just making the image hidden would solve the problem, or would be need to change it to a static image for it to go away?
Nope, making it hidden should solve the problem. I'm not sure if the timers will keep firing though, but we should at least not draw it.
Created attachment 367373 [details] [diff] [review] style patch So this is the patch that I would probably look at using, low impact just uses style rules to hide the image. I haven't tested that this definitely works yet but it should. However now that I've looked at that it seems kind of silly that the deck widget doesn't just effectively do this itself. Regardless of whether it uses native widgets or not does it really have no way to effectively hide the invisible children?
Yeah, it could very well be a more core problem.. in theory those should be hidden! So it could just be that we're not stopping invalidation for hidden animated images, which would be bad.
9 years ago
tracking-fennec: --- → ?
So ideally we should just fix this in core. However if that isn't a possibility for the 1.9.1 branch and it is a real issue for Fennec then we can just take this patch there as a wallpaper measure. I should be able to verify that the style rules are applying but I'm not sure how to verify whether we still see repaints, would checking that no MozAfterPaints are dispatched be enough?
Oh, I misread the patch... it doesn't know anything about decks, it only looks at the visibility style; so it won't fix this bug, I think.
No longer depends on: 483841
Comment on attachment 367373 [details] [diff] [review] style patch Can all of that stuff go into toolkit/mozapps/extensions/content/extensions.css?
(In reply to comment #9) > (From update of attachment 367373 [details] [diff] [review]) > Can all of that stuff go into > toolkit/mozapps/extensions/content/extensions.css? It could, we have a load of stuff in the theme styles that really should be moved into content, I just haven't got around to it yet.
mfinkle: is this an issue for fennec with the new addons manager?
Fennec doesn't do this in the add-ons manager
Fennec now uses its own add-ons manager UI and so shouldn't suffer this problem there, certainly no changes to the toolkit add-ons manager will help. I don't think there is a need to fix this for normal Firefox for now so I'm going to close this. Ideally if there is areal underlying problem then that should be fixed in core rather than trying to catch all the cases around that might cause it.
Assignee: dtownsend → nobody
Status: NEW → RESOLVED
tracking-fennec: ? → ---
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.