810592 - Add-ons manager has full page invalidation

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Mayank Bansal]

Attachment: about support.txt

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0
Build ID: 20121110030714

Steps to reproduce:

1. Enable debug flash
2. open Add-ons manager.
3. Open the "get add-ons " tab
4. wait for loading the page
5. Scroll.

If you have enough Extensions or plugins to warrant a scroll, this can be repro on extensions and add-ons tab too.


Actual results:

Full page constant invalidation


Expected results:

minimal invalidation.


This also happens on FF15. So this is not a recent regression.

Comment 1

[Andre Klapper]

What is a "constant invalidation"?

Comment 2

[Mayank Bansal]

it means that when you are scrolling, the page is repainting again and again.

Comment 3

[[:Aleksej]]

No regression range found with the pref —
nglayout.debug.paint_flashing has no effect: 2011-11-01 03:11:08.en-US.linux-x86_64
reproduced: 2011-11-18 03:10:05-en-US-x86_64

Comment 4

[Matt Woodrow (:mattwoodrow)]

Attachment: Make iframes with active scrolling build their own layer

This is because the clip that we cache for display items is a stack of clips, and some components of the clip are above the frame that is scrolled.

Attempting to shift the combined clip to compensate for scrolling results in the wrong area, and with rounded corner clipping we invalidate the union of the areas.

Creating an nsDisplayOwnLayer for the iframe separates the clips so that this doesn't occur. I wonder if we want to do this for all actively scrolled frames, not just subdocuments.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #4)
> Creating an nsDisplayOwnLayer for the iframe separates the clips so that
> this doesn't occur. I wonder if we want to do this for all actively scrolled
> frames, not just subdocuments.

I think that would work. We probably shouldn't try to do it on FF18 though!

Comment 6

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1c96b4a67d38

Comment 7

[Ed Morley [:emorley]]

Push backed out for reftest failures:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=d30b99cfd933&jobname=%20reftest

https://hg.mozilla.org/integration/mozilla-inbound/rev/dd00a3bad021

Comment 8

[Matt Woodrow (:mattwoodrow)]

https://tbpl.mozilla.org/?tree=Try&rev=4deae6830bce

https://hg.mozilla.org/integration/mozilla-inbound/rev/f573247bb449

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/f573247bb449

Comment 10

[Alex Keybl [:akeybl]]

Please nominate for uplift as soon as you're confident with the change on m-c.

Comment 11

[Paul Silaghi, QA [:pauly]]

(In reply to mayankleoboy1 from comment #2)
> it means that when you are scrolling, the page is repainting again and again.

I'm not seeing a stable painting in Addons Manager on Nightly 20.0a1 (2012-12-02)

Comment 12

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 682980 [details] [diff] [review]
Make iframes with active scrolling build their own layer

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Not a regression, always performed badly
User impact if declined: Slow scrolling within iframes with rounded rect clipping.
Testing completed (on m-c, etc.):  Been on m-c for a week.
Risk to taking this patch (and alternatives if risky): Fairly low risk, just changes how we break up the retained content.
String or UUID changes made by this patch: None

Comment 13

[Alex Keybl [:akeybl]]

Comment on attachment 682980 [details] [diff] [review]
Make iframes with active scrolling build their own layer

This is a "regression" from DLBI. Approving for Aurora/Beta given where we are in the cycle and the risk profile of this fix.

Comment 14

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/bf1ceb185f0c
https://hg.mozilla.org/releases/mozilla-beta/rev/7d4da1832dcc

Comment 15

[Mayank Bansal]

Is this patch present in the latest Nightly ?

Comment 16

[Paul Silaghi, QA [:pauly]]

(In reply to mayankleoboy1 from comment #15)
> Is this patch present in the latest Nightly ?

It should be, but I don't think it's really fixed as I already said in comment 11. The same unstable painting is seen in FF 18b3.

Comment 17

[Mayank Bansal]

FWIW, with HWA off, the issue is much worse.

Comment 18

[Paul Silaghi, QA [:pauly]]

[qa?] based on comment 16