1169331 - Text hugely stretched vertically during vert. scrolling of list

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Jim Avera]

Attachment: FF_scrolllist_renderbug.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150511103303

Steps to reproduce:

Visit https://www.mageia.org/en/about/2010-sept-announcement.html#people
and scroll through the list of people (there will be two scroll-bars: One for the whole page, which is very long, and a second "inner" scroll bar for the list of people).



Actual results:

While scrolling in the list, lines will suddenly elongate vertically to consume most of the list viewport, then collapse back to normal as the scroll progresses.

===> Please see the attached screen-shot


Expected results:

Lines should scroll by normally without being periodically blown up to huge height.

Comment 1

[Jim Avera]

Update: The bug seems to occur only when you first start at the top of the page and then scroll down to the "People" section with the mouse wheel (not by manipulating the scroll bar directly).  THEN grab the inner-most scroll bar to scroll the list of people, and the rendering problem happens.

Please start by visiting https://www.mageia.org/en/about/2010-sept-announcement.html
(without the #people id suffix given in the original post) and use the scroll-wheel to bring the "People" section into view.

Comment 2

[Alice0775 White]

[Tracking Requested - why for this release]: Rendering problem on ESR38 on Ubuntu14.04

Comment 3

[Alice0775 White]

Graphics of the version with the defect

Graphics
--------

Adapter Description: VMware, Inc. -- Gallium 0.4 on SVGA3D; build: RELEASE;
Asynchronous Pan/Zoom: none
Device ID: Gallium 0.4 on SVGA3D; build: RELEASE;
Driver Version: 2.1 Mesa 10.1.3
GPU Accelerated Windows: 0/1 Basic (OMTC)
Supports Hardware H264 Decoding: false
Vendor ID: VMware, Inc.
WebGL Renderer: VMware, Inc. -- Gallium 0.4 on SVGA3D; build: RELEASE;
windowLayerManagerRemote: true
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0

Comment 4

[Alice0775 White]

This have been broken since Firefox34 at least.


And was fixed in cycle of Nightly40.
Fixed range
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4d6d69f0f499&tochange=d0fc7202b4cb

Comment 5

[Nicolas Silva [:nical]]

Markus, looks like one of your patches fixed the issue, do you think you could identify which part and if it is worth uplifting ?

Comment 6

[Markus Stange [:mstange]]

All those patches need to land together, and they're way too risky to uplift. Moreover, this is not the kind of bug they should have fixed; they might have jiggled things around so that we don't hit the code path with the bug, so the real bug will probably still exist somewhere. (For example, those patches made us use opaque layers where we were using transparent layers before in some cases, and the reverse.)

I'll see whether I can reproduce the problem under rr (or whether it's an xrender bug).

Comment 7

[Markus Stange [:mstange]]

This reproduces under rr. :-)

Comment 8

[Sylvestre Ledru [:Sylvestre]]

[Tracking Requested - why for this release]:
Clearly not a driver for a 38 dot releases.
If we have a safe patch, why not uplifting it to 39.

ESR sounds unlikely as we have this bug since Fx 34.

Comment 9

[jen strickland :jenstrickland]

Tracked for 39. We're about to ship beta 3, but this could ship in beta 4, if you land a patch.

Comment 10

[Markus Stange [:mstange]]

(In reply to Alice0775 White from comment #3)
> Graphics of the version with the defect
> 
> Graphics
> --------
> 
> Adapter Description: VMware, Inc. -- Gallium 0.4 on SVGA3D; build: RELEASE;
> Asynchronous Pan/Zoom: none
> Device ID: Gallium 0.4 on SVGA3D; build: RELEASE;
> Driver Version: 2.1 Mesa 10.1.3
> GPU Accelerated Windows: 0/1 Basic (OMTC)

The OMTC part here confuses me. Alice, can you confirm that this bug is really reproducible in a build that uses OMTC? I've only been able to reproduce it without OMTC, and in most builds I've tried, setting layers.offmainthreadcomposition.enabled to true didn't even cause OMTC to be turned on.

Comment 11

[Markus Stange [:mstange]]

Attachment: MozReview Request: Bug 1169331 - Always clip rotated buffer quadrant drawing to the fill rect. r?jrmuizel

Bug 1169331 - Always clip rotated buffer quadrant drawing to the fill rect. r?jrmuizel

Comment 12

[Alice0775 White]

(In reply to Markus Stange [:mstange] from comment #10)
> (In reply to Alice0775 White from comment #3)
> > Graphics of the version with the defect
> > 
> > Graphics
> > --------
> > 
> > Adapter Description: VMware, Inc. -- Gallium 0.4 on SVGA3D; build: RELEASE;
> > Asynchronous Pan/Zoom: none
> > Device ID: Gallium 0.4 on SVGA3D; build: RELEASE;
> > Driver Version: 2.1 Mesa 10.1.3
> > GPU Accelerated Windows: 0/1 Basic (OMTC)
> 
> The OMTC part here confuses me. Alice, can you confirm that this bug is
> really reproducible in a build that uses OMTC? I've only been able to
> reproduce it without OMTC, and in most builds I've tried, setting
> layers.offmainthreadcomposition.enabled to true didn't even cause OMTC to be
> turned on.

My bad, reproduced w/o OMTC.

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Markus is this ready to land ? Or are you still working on it? Thanks.

Comment 14

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=74d2ace18c62

Comment 15

[Markus Stange [:mstange]]

Just need to wait for the tryserver results, then I'll land it.

Comment 16

[Markus Stange [:mstange]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/67527d8c0688

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Backed out for being the most-likely cause of semi-frequent Android debug reftest failures like the log shown below:
https://treeherder.mozilla.org/logviewer.html#?job_id=10679939&repo=mozilla-inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/99d6da0042f3

Comment 18

[Markus Stange [:mstange]]

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

Comment 19

[Markus Stange [:mstange]]

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

Comment 20

[Markus Stange [:mstange]]

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

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/a490322a1877
https://hg.mozilla.org/mozilla-central/rev/b9562bd4954b
https://hg.mozilla.org/mozilla-central/rev/cf373ad45129

Comment 22

[Markus Stange [:mstange]]

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

Comment 23

[Liz Henry (:lizzard) (relman/hg->git project)]

Markus or Jeff, do you want to request uplift for this at least to aurora? May be a bit late for beta unless you think it is super important not to ship this with 39 and you can verify it works on nightly.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

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

Comment 25

[Liz Henry (:lizzard) (relman/hg->git project)]

Just realized aurora is unaffected. Wontfix for 39 since at this point we are pretty focused on stability and security fixes.