Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Description • 10 years ago

The attached testcase should be opacity:0.5 blue, and it is in Blink, but in Gecko it's blank.

d2's nsDisplayOpacity gets a clip set it on it from d1, because d1 is the containing block for d2. So the entire opacity group, including d3, gets clipped. But d1 is not a containing block ancestor of d3, so d3 should not be clipped.

The solution is probably to just not clip nsDisplayOpacity in BuildDisplayListForStackingContext. Instead we should let the current clip be passed down to the descendant display items.

Note that the same problem occurs for filters and mix-blend-mode, but in those cases the correct rendering is unclear (in fact, both Gecko and Chrome clip d3 in the filters case). I've requested spec feedback in http://lists.w3.org/Archives/Public/public-fx/2015JanMar/0002.html, and the results of that feedback will determine how we handle those features. In the meantime we should definitely fix opacity.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 2 • 10 years ago

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=1d835cdc682a

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 3 • 10 years ago

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

	:Ms2ger (he/him; ⌚ UTC+1/+2)
	Comment 4 • 10 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 5 • 10 years ago

Failed test: http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-inbound-emulator/1420898370/mozilla-inbound_ubuntu64_vm-b2g-emulator_test-reftest-3-bm115-tests1-linux64-build983.txt.gz&only_show_unexpected=1

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 6 • 10 years ago

The failing test is an async-scrolled DIV containing an opacity:0.5 element with two yellow children, one abs-pos, one not. ScrollFrameHelper::ComputeFrameMetrics computes a cliprect which we apply to the ContainerLayer for the opacity:0.5 element, reintroducing this bug.

As the comment in ContainerState::SetupScrollingMetadata says, when a ContainerLayer has a child layer whose animated geometry root is not a descendant of the ContainerLayer's animated geometry root, async scrolling does not work currently. That would be a lot of work to fix. That's the situation we're in here, though it's worse, because instead of just scrolling lagging, a chunk of an element is being incorrectly clipped out.

Avoiding this problem looks hard. We must have a single ContainerLayer for the opacity:0.5 element because the contents must be blended as a group. If we avoid putting a cliprect on that ContainerLayer (following the approach taken for the display item in the patch in this bug), we'll have to clip the child layers, but then those clips will be affected by the async scrolling transform. So this is complicated to fix and even then won't work well.

I think I'll just mark this test as failing for now. It's only passing on trunk because the non-async-scroll reference rendering is incorrect. This patch fixes the reference to render correctly, causing the test to fail.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 7 • 10 years ago

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

	Carsten Book [:Tomcat]
	Comment 8 • 10 years ago

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