777753 - Occasional slow repaint on scrolling fast around on Facebook news feed on FxOS

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: General, defect)

Description

[Jason Smith [:jsmith]]

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.

Comment 1

[Chris Lee [:clee]]

Is this on m.facebook.com or on touch.facebook.com and/or does it make any difference?

This is a blocker.

Comment 2

[Andrew Overholt [:overholt]]

Joe, who should own this?

Comment 3

[Joe Drew (not getting mail)]

Jeff should profile this to start.

Comment 4

[Joe Drew (not getting mail)]

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.

Comment 5

[Joe Drew (not getting mail)]

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.

Comment 6

[Andreas Gal :gal]

Does paint flashing work for you now?

Comment 7

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Is this still an issue now that DLBI has landed?

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

can't test in 10/12 build because of bug 800817; will need to verify in a different build.

Comment 10

[Jason Smith [:jsmith]]

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

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Lowering to P2 based on that.

Comment 12

[Jason Smith [:jsmith]]

(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?

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

We seem to be repainting a lot on facebook now. I've filed bug 802353

Comment 15

[Hubert Figuiere [:hub]]

Please reopen if you think it still applies. Thanks.