Build Device: Otoro Build: 7/25/2012 Steps 1. Open the browser 2. Go to facebook.com 3. Login 4. Start scrolling down your news feed quickly Expected The repaint should be quick enough to keep up with the user's scrolling rate on the page as they move up and down the news feed quickly. Actual As you scrolldown the news feed, repainting doesn't appear to happen quickly enough. This results in a large whitespace being shown to the user quickly as they scroll down the news feed. This can happen on other places on facebook.com as well.
Is this on m.facebook.com or on touch.facebook.com and/or does it make any difference? This is a blocker.
Joe, who should own this?
Assignee: nobody → joe
Jeff should profile this to start.
Assignee: joe → jmuizelaar
Hm, Jeff says that we need to make sure we're invalidating correctly, which can be tested by using paint flashing. I'll do that, since Jeff is a poopy head.
Assignee: jmuizelaar → joe
I can't debug this for two reasons: I can't get wifi to work on my device when I build B2G (bug 784524), but even when I use a prebuilt image, paint flashing doesn't work (bug 784525). Over to Jeff for profiling regardless.
Assignee: joe → jmuizelaar
Does paint flashing work for you now?
So we're not over painting a lot on this page, however we also have painting corruption on this page so we could be not painting by mistake (filed bug 788682) I'll still profile this to see where the time is being spent.
6 years ago
Whiteboard: [WebAPI:P0] → [WebAPI:P0][LOE:M]
Is this still an issue now that DLBI has landed?
can't test in 10/12 build because of bug 800817; will need to verify in a different build.
(In reply to Jonas Sicking (:sicking) from comment #8) > Is this still an issue now that DLBI has landed? Reproducible in a much lower severity and less probability. It's much better than the last time I tested. Probably acceptable for v1. We might want to keep this open as a form of polish, however, as there are some occasional repaint issues if you scroll fast. But not bad enough to block v1 ship.
blocking-basecamp: + → ---
Summary: Repaint on scrolling around on facebook is quite slow when reading a news feed → Occasional slow repaint on scrolling fast around on facebook news feed on FF OS
Lowering to P2 based on that.
Priority: P1 → P2
(In reply to Jonas Sicking (:sicking) from comment #11) > Lowering to P2 based on that. I actually removed the basecamp nom cause I don't think this blocks ship based on the probability and severity I saw. Do we still want priorities on bugs that are not blocking? Or do you feel strongly that should still be a blocker?
Priorities are effectively handled very different for different triage efforts. So if this isn't a blocker (and I'm happy to take your word on that) then keeping the priority doesn't make much sense.
Priority: P2 → --
Summary: Occasional slow repaint on scrolling fast around on facebook news feed on FF OS → Occasional slow repaint on scrolling fast around on Facebook news feed on FxOS
Whiteboard: [LOE:M] → [c= p= s= u=] [LOE:M]
Please reopen if you think it still applies. Thanks.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
Whiteboard: [c= p= s= u=] [LOE:M] → [c= p= s=2013.09.20 u=] [LOE:M]
You need to log in before you can comment on or make changes to this bug.