Created attachment 710321 [details] Screenshot Steps to reproduce: 1. Open URL, 2. Scroll slowly or fast, Expected result: Should scroll without artifacts. Actual result: Artifacts while scrolling. Reproducable one multiple phones. Not reproducable in Chrome.
This one is really bad, the only reason it doesn't look worse is that it seems to expose some bad invalidation behaviour too (possibly as the result of things becoming active/inactive when scrolling) and things get redrawn correctly. Need to test to determine if this happens with progressive tile updates/cancelling off.
I think this is a regression, it could possibly be related to bug 808746 - the single paint buffer has an issue drawing non-opaque content, as it fails to clear at the right times... Perhaps the single paint buffer is getting used somehow and this bug is being exposed? It'd be good to get a regression range, adding some relevant keywords.
The regression window for this issue is: good build: 2012/11/16 bad build 2012/11/17 possible push-log: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58ebb638a7ea&tochange=9a6d708faf3f
150 change-sets in there, I think that will require bisecting unless there's something that sticks out
Mounir, is comment 3 good enough to narrow a range?
I am not sure what you mean. Are you expecting me to try the range? If you can point me to a build from the 16th and another from the 17th, I would gladly check if I can indeed reproduce the issue or not on them.
(In reply to Mounir Lamouri (:mounir) from comment #6) > I am not sure what you mean. Are you expecting me to try the range? If you > can point me to a build from the 16th and another from the 17th, I would > gladly check if I can indeed reproduce the issue or not on them. sorry i wasnt clear. i was asking if the push log from comment 3, is easy enough to spot if a clear regression is found. Andreea already reproduced the issue on 11/17, so no need to retest. possible push-log: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58ebb638a7ea&tochange=9a6d708faf3f
I dont see this at all on latest trunk; tested on my Nexus 4. Anyone else?
I strongly suspect this was fixed by bug 850396.
Alrighty Mounir re-open if you still see this