1189159 - [e10s] GMail folder list does not repaint when APZC is enabled

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Vladan Djeric (:vladan)]

Attachment: gmail not repainting in e10s.png

STR
1. Log into GMail
2. Expand the "More" label from the sidebar to see a list of additional GMail folders in the sidebar

Actual: The expanded list of folders (e.g. Chats/All Mail/Receipts/Work) is only partially repainted. Collapsing and expanding the folders again using "More" and "Less" produces the same artifacts.

This is 100% reproducible with e10s Nightly from 20150729 on my Windows 7 machine. The bug does not reproduce with e10s disabled.

Comment 1

[Vladan Djeric (:vladan)]

Attachment: about:support

Comment 2

[Vladan Djeric (:vladan)]

This bug does not reproduce on the latest Aurora 41

Comment 3

[George Wright (:gw280) (needinfo me!)]

Can you test this with and without APZC enabled please?

Comment 4

[Vladan Djeric (:vladan)]

The bug goes away with APZC disabled, needinfo-ing kats

Btw, I was able to reproduce this on second machine (a recent i3 with HD5000 gfx), but not on an older Optimus i7 with Quadro 1000M & HD 3000)

Comment 5

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

CC'ing me is sufficient :)

I can't repro this on OS X but it looks bad, so making it block all-aboard-apz.

Comment 6

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

(Vladan said it repro's on Win 8.1 also)

Comment 7

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

I can repro this on my personal gmail account but not the mozilla google apps account (on windows but not on OSX). It seems to be some sort of invalidation bug; mousing over the items in the expanded box makes them repaint properly.

Comment 8

[David Anderson [:dvander] - inactive, e-mail if emergency]

I can reproduce this on Linux, but only with BasicCompositor. Repros on corporate gmail.

Comment 9

[David Anderson [:dvander] - inactive, e-mail if emergency]

Okay, I think I finally found the problem here.

The navigation box and contact list are both scrollable divs, and both have displayports. Clicking "More" in the navbox expands its scrollport, revealing the rest of the displayport, pushing the contact list down. This is animated. As the contact list moves down, portions of the text it should be revealing appear to not be painted.

However, this text is rendered into a displayport, so it *is* painted. It hasn't changed so its display item doesn't need to be invalidated. The problem is that the compositor's update region doesn't include the rect where the text should be visible, so we may not necessarily composite it.

Normally a scrollport change would invalidate its contents, but APZ explicitly avoids that with displayports. Instead we would expect that the layer's clip would change, and then we'd invalidate the clip difference: but with APZ, the clip is on the FrameMetrics, which isn't checked in LayerTreeInvalidation.

So I think all we have to do to fix this is compare the clip rects in the old and new FrameMetrics. I'll try this tomorrow.

Comment 10

[David Anderson [:dvander] - inactive, e-mail if emergency]

Matt pointed out that we should actually just be using the shadow clip instead, since invalidation happens after async composition. Tested locally and that seems to fix the problem.

Comment 11

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: bug1213324.patch

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2bc866307e4b

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

This appears to have caused m-e10s(1) permafail on linux: https://treeherder.mozilla.org/logviewer.html#?job_id=16050110&repo=mozilla-inbound

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/59164fa9fe90

Comment 14

[Pulsebot]

Backout:
https://hg.mozilla.org/mozilla-central/rev/4879f22ef96a

Comment 15

[David Anderson [:dvander] - inactive, e-mail if emergency]

It seems extremely unlikely that this failure could be related to a change in compositor clipping, so I'm not sure what that's about. But Matt pointed out that this patch could lead to over-invalidation if we receive a layers update in between composites with no clip rect. The best way to address this is to only compute invalidation on composites, so I'll file an additional bug for that.

Comment 16

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2df18499b6ad

Comment 17

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/2df18499b6ad