The default bug view has changed. See this FAQ.

Google PDF Viewer pane gets rendered misplaced when you scroll down

VERIFIED FIXED in Firefox 16

Status

()

Core
Graphics: Layers
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Ehsan, Assigned: cwiiis)

Tracking

({regression})

Trunk
mozilla17
x86
All
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15 unaffected, firefox16 verified, firefox17 verified)

Details

(Whiteboard: [testday 20121005])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Open <https://docs.google.com/open?id=1FnQSo7vEAu_aNIQae9DfVrSqOBWr0ZOqBW1CQeUQxYjfnCeUcu2QgYgeyGGG> and scroll down very slowly.  Seems to only happen with hw accel.

Comment 1

5 years ago
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: 539356
Keywords: regression
OS: Mac OS X → All
Assignee: nobody → chrislord.net
(Assignee)

Comment 2

5 years ago
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.
(Assignee)

Comment 3

5 years ago
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.
(Assignee)

Comment 4

5 years ago
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.
(Assignee)

Comment 5

5 years ago
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...
(Assignee)

Comment 6

5 years ago
I think this may be a duplicate of Bug 767292.
(Assignee)

Comment 7

5 years ago
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.
(Assignee)

Comment 8

5 years ago
(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...
(Assignee)

Comment 9

5 years ago
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.
Attachment #650513 - Flags: review?(roc)
Attachment #650513 - Flags: review?(roc) → review+
(Assignee)

Comment 10

5 years ago
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
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
(Assignee)

Comment 12

5 years ago
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?
status-firefox15: --- → unaffected
status-firefox16: --- → affected
status-firefox17: --- → fixed
What kind of breakage do you think this could cause? Is there something we can give QA to test on central/Aurora for this?
(Assignee)

Comment 14

5 years ago
(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+
(Assignee)

Comment 16

5 years ago
Pushed to aurora: http://hg.mozilla.org/releases/mozilla-aurora/rev/6cd5b6d1b4bc
status-firefox16: affected → fixed
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.
status-firefox16: fixed → verified
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
status-firefox17: fixed → verified
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.