1644599 - Page content is not updated until some interactions

Status: NEW

(Core :: Web Painting, defect, P3)

Description

[Emily Kager [:ekager]]

Originally filed: https://github.com/mozilla-mobile/fenix/issues/11356

Steps to reproduce

1. Open https://m.vk.com/like?act=members&object=wall-22822305_1097944
2. Go to bottom
3. Click on "likes" page number (2-3, for example)
4. Click on another page number (but not last page)

Also see comment:

One thing I realized is that on Fenix when the step 4 is done, the scroll position keeps at the bottom, whereas on Chrome it's reset to the top for some reasons.

Expected behavior

Content of page changed without any interaction

Actual behavior

Sometimes it works as expected
Sometimes no response, until you interact with page (scroll page)

Device information

• Android device: 7.0 on Samsung S6 Edge
• Fenix version: Looks like all Fenix versions is affected (also old Firefox for Android affected)

Comment 1

[Botond Ballo [:botond]]

S3 for an issue that looks like it has been around for a long time (affecting Fennec as well).

Also cc'ing some webcompat folks in case it rings a bell.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

I can reproduce the problem in Fennec easily enough. Initially I thought it might be that we weren't doing a composite but I don't think that's the case, because when at the bottom, after clicking on the page number, I can do some overscroll which makes the scrollbar appear and that's definitely doing composites. And in fact I think the scrollbars appearing/disappearing means that main-thread paints are happening too. So either the paint is painting the wrong thing, or the DOM hasn't been updated yet or something. Seems like a problem earlier in the pipeline and not so much APZ.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I thought I moved this bug but apparently I did not. Meant to move it to web painting so somebody more familiar with the invalidation code can take a look. No idea if this bug still repros though.