Transition paint wrong fragments at the end of transition for 1-2 seconds.

VERIFIED FIXED

Status

()

Core
Layout
VERIFIED FIXED
7 years ago
4 years ago

People

(Reporter: Dumbo 12, Assigned: roc)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [hardblocker][has patch], URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10) Gecko/20100101 Firefox/4.0b10
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10) Gecko/20100101 Firefox/4.0b10

While playing around I find this bug.
It happens ONLY if you have an transition inside of an object that is also in transition.
At the and of all transition the Object show for 1-2 seconds a wrong "picture". (sorry my english)

Reproducible: Always

Steps to Reproduce:
<!DOCTYPE HTML>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Untitled Document</title>
<style type="text/css">
body {
	font-size: 10px;
}

.test {
	position: absolute;
	top: -35em;
	right: 50em;
	display: inline-block;
	border: 3px solid #000;
	border-radius: 0.8em;
	padding: 1em;
	min-width: 30em;
	min-height: 30em;
	
	transform: rotate(45deg);
	-webkit-transform: rotate(45deg);
	-moz-transform: rotate(45deg);
	-o-transform: rotate(45deg);
	
	-webkit-transition: all 1s linear;  
    -moz-transition: all 1s linear;  
    -o-transition: all 1s linear;  
    transition: all 1s linear; 
}

.test:hover {
	top: -1em;
	transform: rotate(0deg);
	-webkit-transform: rotate(0deg);
	-moz-transform: rotate(0deg);
	-o-transform: rotate(0deg);
}






.test2 {
	display: inline-block;
	position: absolute;
	top: -17em;
	right: 40em;
	min-width: 20em;
	min-height: 20em;
	
	-webkit-transition: all 1s linear;  
    -moz-transition: all 1s linear;  
    -o-transition: all 1s linear;  
    transition: all 1s linear; 
}

.test2:hover {
	top: 0em;
}

.test2 div {
	background: red;
	min-height: 20em;
	
	-webkit-transition: all 1s linear;  
    -moz-transition: all 1s linear;  
    -o-transition: all 1s linear;  
    transition: all 1s linear; 
	
	transform: rotate(45deg);
	-webkit-transform: rotate(45deg);
	-moz-transform: rotate(45deg);
	-o-transform: rotate(45deg);
}

.test2 div:hover {
	transform: rotate(0deg);
	-webkit-transform: rotate(0deg);
	-moz-transform: rotate(0deg);
	-o-transform: rotate(0deg);
}
</style>
</head>

<body>
	<div class="test">
        <input name="testinp" type="text">
    </div>
    
    <div class="test2">
        <div>test</div>
    </div>
</body>
</html>




This happens on Mac (OSX 10.6) and Windows 7. 
On Windows the wrong painting is not so heavy as on mac.

On google chrome and on safari it works right.
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → style-system
Version: unspecified → Trunk
Created attachment 509090 [details]
Testcase

Hover the red square to see the problem.
I definitely see this on Mac.  This is really bad.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Component: Style System (CSS) → Graphics
Ever confirmed: true
Keywords: regression
QA Contact: style-system → thebes
The problem goes away if I disable hardware acceleration.
Keywords: testcase
Tentatively calling this a hardblocker, because it indicates bugs in our container layers. The fact that it happens on both OS X and Windows is troubling, though...
Assignee: nobody → matt.woodrow+bugzilla
blocking2.0: ? → final+
Whiteboard: [hardblocker]
Keywords: regressionwindow-wanted
FWIW I can't reproduce on unaccelerated Linux and unaccelerated Windows (2000).
Something to do with antialiasing I guess. There's also some kind of black-edge artifact during the animation, on Windows. Bas might know about this.
(Reporter)

Comment 7

7 years ago
There also a second problem if you look at my page: http://designgarden.cubernatic.com/home2/ you will see a div element with round corners that at the middle of the page. 
While loading you see the painting process. Thats really ugly. And funny it not happens with the elements on top of the page.

Any ideas to this behavior?
This looks like a regression from component alpha landing, and appears to be a layout bug.

In ContainerLayerOGL.cpp (line 178) we are detecting a fully opaque layer and not clearing the surface.

With this testcase I get a visible rect (for the container) of:

(gdb) p visibleRect
$1 = {
  x = 889, 
  y = -56, 
  width = 252, 
  height = 252, 
  static kMaxSizedIntRect = {
    x = 0, 
    y = 0, 
    width = 2147483647, 
    height = 2147483647, 
    static kMaxSizedIntRect = <same as static member of an already seen type>
  }
}

Yet the red rectangle measures 202 pixels in both dimensions. This really doesn't sound like a fully opaque layer at all.

Changing this code to clear the framebuffer partially fixes the testcase and leaves us with bug 622585 (though would break component alpha of course).
Frame tree dump of a nearby paint (not the exact same one as the above example).

OGLLayerManager (0x1f8805e0)
  OGLContainerLayer (0x1f8af280) [visible=< (x=0, y=0, w=1440, h=765); >] [opaqueContent] [metrics={ viewport=(x=0, y=0, w=1440, h=765) viewportScroll=(x=0, y=0) displayport=(x=0, y=0, w=0, h=0) scrollId=0 }]
    OGLThebesLayer (0x1f8aff20) [visible=< (x=0, y=0, w=1440, h=65); >] [opaqueContent] [valid=< (x=0, y=0, w=1440, h=65); >]
    OGLContainerLayer (0x1aa87fa0) [clip=(x=0, y=65, w=1440, h=700)] [visible=< (x=0, y=65, w=1440, h=700); >] [opaqueContent]
      OGLThebesLayer (0x1aa88100) [transform=[ 1 0; 0 1; 0 65; ]] [visible=< (x=0, y=0, w=1440, h=700); >] [opaqueContent] [valid=< (x=0, y=0, w=1440, h=700); >]
      OGLContainerLayer (0x1b071d20) [clip=(x=0, y=65, w=1440, h=700)] [transform=[ 0.726814 0.686834; -0.686834 0.726814; 257.561 -645.319; ]] [visible=< (x=880, y=-50, w=261, h=252); >] [opaqueContent]
        OGLThebesLayer (0x1b071e80) [transform=[ 1 0; 0 1; 0 65; ]] [visible=< (x=881, y=-115, w=159, h=152); >] [valid=< (x=881, y=-115, w=159, h=152); >]
Assignee: matt.woodrow+bugzilla → nobody
QA Contact: thebes
Component: Graphics → Layout
QA Contact: layout
Blocks: 622585
Assignee: nobody → roc
Hmm, I was seeing this, but now I'm not. Has this gone away by itself?
Ah no, I still see it with D3D10.
Created attachment 511529 [details] [diff] [review]
fix

Everything's described in the patch.
Attachment #511529 - Flags: review?(tnikkel)
Whiteboard: [hardblocker] → [hardblocker][needs review]
Created attachment 511560 [details] [diff] [review]
v2

The previous patch caused lots of assertions because our computation of the chlid list bounds didn't take clipping into account.
Attachment #511529 - Attachment is obsolete: true
Attachment #511560 - Flags: review?(tnikkel)
Attachment #511529 - Flags: review?(tnikkel)

Updated

7 years ago
Whiteboard: [hardblocker][needs review] → [hardblocker][needs review][has patch]
This patch seems to cause
REFTEST TEST-START | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/579808-1.html
++DOMWINDOW == 107 (0F705C58) [serial = 5738] [outer = 080A1D80]
For application/x-test found plugin nptest.dll
###!!! ASSERTION: Wrong bounds: 'bounds == aChildren.GetBounds(aBuilder)', file e:/builds/moz2_slave/try-w32-dbg/build/layout/base/FrameLayerBuilder.cpp, line 1598
I cannot reproduce that assertion locally. Did you get it locally or on a tryserver build?
On tryserver (win32).
You tryservered v2 right? Do you have a link to the output still?
Pretty sure it was v2.

http://tbpl.mozilla.org/?tree=MozillaTry&pusher=tnikkel@gmail.com&rev=3c06775de791

Note that there were other things in the push, so it is not certain to be yours (but seems likely).
Yeah.

Can you try reproducing it locally?
It doesn't happen locally on my Linux machine with the patch in this bug.
How do you feel about marking the test as 0-1 assertions?
(In reply to comment #21)
> How do you feel about marking the test as 0-1 assertions?

I don't know yet, have to review the patch first.
I pushed some diagnostics to try, this should help sort it out.
http://tbpl.mozilla.org/?tree=MozillaTry&rev=b79e0cf7cfc9
Looks like the output of that was

Plugin 1460DEC0(ObjectFrame(embed)(1)) (6480,6480,0,0)(480,480,12000,12000)
bounds=480,480,12000,12000 computed=0,0,0,0
That makes it look like the bounds returned 480,480,12000,12000 once and then later returned 6480,6480,0,0. So I was thinking about how this could happen. I guess it could happen when nsObjectFrame::BuildLayer calls mInstanceOwner->SetCurrentImage, changing the image. I still don't fully understand the sequence of events, but it's definitely a problem that nsDisplayPlugin can change its bounds during layer tree construction!
I'll fix that in bug 631388.
Depends on: 631388
Is bug 634784 related to this, by any chance?
Keywords: regressionwindow-wanted
Whiteboard: [hardblocker][needs review][has patch] → [hardblocker][needs review tnikkel][has patch]
Comment on attachment 511560 [details] [diff] [review]
v2

+  nsRect bounds = state.GetChildrenBounds();
+  NS_ASSERTION(bounds == aChildren.GetBounds(aBuilder), "Wrong bounds");

So this means that mBounds, the code for updating it, and GetChildrenBounds is basically debug only code then?
It's an optimization. aChildren.GetBounds makes us walk the child list again. I should add a comment to explain that.
Attachment #511560 - Flags: review?(tnikkel) → review+
Whiteboard: [hardblocker][needs review tnikkel][has patch] → [hardblocker][depends on 631388][has patch]
http://hg.mozilla.org/mozilla-central/rev/b8194445b364
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [hardblocker][depends on 631388][has patch] → [hardblocker][has patch]

Updated

7 years ago
Depends on: 636229
Verified on Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Status: RESOLVED → VERIFIED

Comment 35

7 years ago
The landing of this bug appears to have resulted in an issue with painting of video controls. Bug 640074.

Updated

7 years ago
Depends on: 654641
Depends on: 697647
You need to log in before you can comment on or make changes to this bug.