Last Comment Bug 779269 - Google PDF Viewer pane gets rendered misplaced when you scroll down
: Google PDF Viewer pane gets rendered misplaced when you scroll down
Status: VERIFIED FIXED
[testday 20121005]
: regression
Product: Core
Classification: Components
Component: Graphics: Layers (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: mozilla17
Assigned To: Chris Lord [:cwiiis]
: Paul Silaghi, QA [:pauly]
Mentors:
Depends on: dlbi
Blocks: 758620
  Show dependency treegraph
 
Reported: 2012-07-31 12:59 PDT by :Ehsan Akhgari (busy, don't ask for review please)
Modified: 2012-10-16 07:58 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
verified
verified


Attachments
Merge FixedPosition items with the same fixed-pos frame (2.20 KB, patch)
2012-08-09 05:37 PDT, Chris Lord [:cwiiis]
roc: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
Details | Diff | Review

Description :Ehsan Akhgari (busy, don't ask for review please) 2012-07-31 12:59:30 PDT
Open <https://docs.google.com/open?id=1FnQSo7vEAu_aNIQae9DfVrSqOBWr0ZOqBW1CQeUQxYjfnCeUcu2QgYgeyGGG> and scroll down very slowly.  Seems to only happen with hw accel.
Comment 1 Alice0775 White 2012-07-31 15:11:59 PDT
1st regression
Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/d254c07f3301
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120627151113
Bad:
http://hg.mozilla.org/mozilla-central/rev/bf8f2961d0cc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120628010552
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d254c07f3301&tochange=bf8f2961d0cc

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/06e7df3a8209
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120627083614
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/7ef9568fbd40
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120627084814
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=06e7df3a8209&tochange=7ef9568fbd40

Suspected: Bug 758620


2nd regression(due to backout bug 539356)
Regression window(m-c):
Good:
http://hg.mozilla.org/mozilla-central/rev/477d807660d7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120703160501
Bad:
http://hg.mozilla.org/mozilla-central/rev/87db9617a885
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120704030538
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=477d807660d7&tochange=87db9617a885
Comment 2 Chris Lord [:cwiiis] 2012-08-07 06:57:57 PDT
Pretty easy to reproduce on a Nightly, but no suspicions as to what this would be... Will have a look at the display-list and such.
Comment 3 Chris Lord [:cwiiis] 2012-08-07 12:10:14 PDT
I haven't been able to reproduce this on Linux yet - I've forced IsCompositingCheap to true to replicate what I assume the layout differences are when acceleration is enabled, and this bug doesn't manifest.
Comment 4 Chris Lord [:cwiiis] 2012-08-07 12:13:10 PDT
This does manifest if you force layers acceleration on in Linux, however. Oddly, when the displaced rendering is invalidated (by being scrolled off, then back on screen), it is redrawn correctly. It seems just the initial draw is incorrect when initiating scrolling.
Comment 5 Chris Lord [:cwiiis] 2012-08-08 02:12:50 PDT
The generated display-list when using acceleration is *very* different to that without - it includes a lot of Opacity items, which don't appear in the unaccelerated list. The resultant layer tree seems quite convoluted too, and it seems some items appear in container layers that don't seem to represent their ordering in the display-list (which would go some way as to explaining this glitch).

Still looking...
Comment 6 Chris Lord [:cwiiis] 2012-08-08 04:25:49 PDT
I think this may be a duplicate of Bug 767292.
Comment 7 Chris Lord [:cwiiis] 2012-08-08 05:04:22 PDT
I take it back, it's unlikely this is a duplicate of bug 767292, just similar manifestations (and perhaps similar causes?)

The problem here seems to be on the first paint, the HTMLScroll(div) of what I assume is the PDF document appears once as a FixedPosition item (which gets turned into a container layer), and then again as a child of that FixedPosition item as a background. This accounts for it being painted twice, I think, and the offset - on subsequent paints, the second incorrect div disappears from the display-list, it's only the first paint after scrolling where this happens.

Will correlate this with the frame-tree to try and see why this is happening.
Comment 8 Chris Lord [:cwiiis] 2012-08-08 06:13:03 PDT
(In reply to Chris Lord [:cwiiis] from comment #7)
> I take it back, it's unlikely this is a duplicate of bug 767292, just
> similar manifestations (and perhaps similar causes?)
> 
> The problem here seems to be on the first paint, the HTMLScroll(div) of what
> I assume is the PDF document appears once as a FixedPosition item (which
> gets turned into a container layer), and then again as a child of that
> FixedPosition item as a background. This accounts for it being painted
> twice, I think, and the offset - on subsequent paints, the second incorrect
> div disappears from the display-list, it's only the first paint after
> scrolling where this happens.
> 
> Will correlate this with the frame-tree to try and see why this is happening.

On further inspection, I feel that this may actually be fine and I've misidentified what's going wrong...
Comment 9 Chris Lord [:cwiiis] 2012-08-09 05:37:13 PDT
Created attachment 650513 [details] [diff] [review]
Merge FixedPosition items with the same fixed-pos frame

I'm still stumped as to *exactly* why this is happening. I can't explain all the things that are happening to the display-list yet, but none of them actually look really wrong as such.

This patch fixes the bug title issue, but I imagine this issue can still be triggered by crafting the page slightly differently. Just uploading it in case it's something we want to do anyway and it's a reasonable work-around.
Comment 10 Chris Lord [:cwiiis] 2012-08-10 01:37:12 PDT
Pushed to inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/46a012b16d3d
Comment 11 Ryan VanderMeulen [:RyanVM] 2012-08-11 19:57:32 PDT
https://hg.mozilla.org/mozilla-central/rev/46a012b16d3d
Comment 12 Chris Lord [:cwiiis] 2012-08-13 20:09:06 PDT
Comment on attachment 650513 [details] [diff] [review]
Merge FixedPosition items with the same fixed-pos frame

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Google PDF viewer has odd rendering artifacts when scrolling
User impact if declined: Sites using fixed-position elements in certain ways may have rendering artifacts and/or bad performance
Testing completed (on m-c, etc.): Been on m-c for a few days with no problems
Risk to taking this patch (and alternatives if risky): Medium risk, could cause sites with fixed-position elements to break in different ways (but I think it should be ok)
String or UUID changes made by this patch: None
Comment 13 Lukas Blakk [:lsblakk] use ?needinfo 2012-08-15 10:20:49 PDT
What kind of breakage do you think this could cause? Is there something we can give QA to test on central/Aurora for this?
Comment 14 Chris Lord [:cwiiis] 2012-08-15 14:18:28 PDT
(In reply to Lukas Blakk [:lsblakk] from comment #13)
> What kind of breakage do you think this could cause? Is there something we
> can give QA to test on central/Aurora for this?

This is mobile only in Aurora - it's hard to say what I expect to happen until it happens, but it's very possible that pages that use a combination of position:fixed and opacity, z-index, animation or any other property that forces layers could potentially have very bad rendering glitches.
Comment 15 Lukas Blakk [:lsblakk] use ?needinfo 2012-08-20 15:32:39 PDT
Comment on attachment 650513 [details] [diff] [review]
Merge FixedPosition items with the same fixed-pos frame

Ok, let's take this on Aurora and watch for any complain when it gets to Beta channel and there are more users on it visiting a wider variety of sites.   If there are terrible regressions we can back out of Beta.
Comment 16 Chris Lord [:cwiiis] 2012-08-22 07:49:13 PDT
Pushed to aurora: http://hg.mozilla.org/releases/mozilla-aurora/rev/6cd5b6d1b4bc
Comment 17 Paul Silaghi, QA [:pauly] 2012-09-19 06:52:12 PDT
Able to see the issue on Nightly 2012-07-21.
Verified fixed on FF 16b3 on Win 7, Ubuntu 12.04 and Mac OS X 10.7.4.
Comment 18 Gabriela [:gaby2300] 2012-10-05 14:34:55 PDT
I can verify the bug is fixed.
Using Win 7 64-bit and today's Aurora build.
Comment 19 Paul Silaghi, QA [:pauly] 2012-10-16 07:58:31 PDT
Thanks Gabriela!
Also verified fixed on FF 17b1 on Win 7 x86, Ubuntu 12.04 and Mac OS X 10.7.4.

Note You need to log in before you can comment on or make changes to this bug.