Closed Bug 779269 Opened 12 years ago Closed 12 years ago

Google PDF Viewer pane gets rendered misplaced when you scroll down

Categories

(Core :: Graphics: Layers, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla17
Tracking Status
firefox15 --- unaffected
firefox16 --- verified
firefox17 --- verified

People

(Reporter: ehsan.akhgari, Assigned: cwiiis)

References

Details

(Keywords: regression, Whiteboard: [testday 20121005])

Attachments

(1 file)

Open <https://docs.google.com/open?id=1FnQSo7vEAu_aNIQae9DfVrSqOBWr0ZOqBW1CQeUQxYjfnCeUcu2QgYgeyGGG> and scroll down very slowly.  Seems to only happen with hw accel.
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
Blocks: 758620
Depends on: dlbi
Keywords: regression
OS: Mac OS X → All
Assignee: nobody → chrislord.net
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.
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.
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.
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...
I think this may be a duplicate of Bug 767292.
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.
(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...
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.
Attachment #650513 - Flags: review?(roc)
Pushed to inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/46a012b16d3d
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/46a012b16d3d
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
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
Attachment #650513 - Flags: approval-mozilla-aurora?
What kind of breakage do you think this could cause? Is there something we can give QA to test on central/Aurora for this?
(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 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.
Attachment #650513 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Keywords: verifyme
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.
QA Contact: paul.silaghi
I can verify the bug is fixed.
Using Win 7 64-bit and today's Aurora build.
Whiteboard: [testday 20121005]
Thanks Gabriela!
Also verified fixed on FF 17b1 on Win 7 x86, Ubuntu 12.04 and Mac OS X 10.7.4.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.