LayoutTests/fast/multicol/composited-with-child-layer-in-next-column.html - Issue 645023002: [New Multicolumn] Make layer bounding boxes visual and relative to "root".

Side by Side Diff: LayoutTests/fast/multicol/composited-with-child-layer-in-next-column.html

Issue 645023002: [New Multicolumn] Make layer bounding boxes visual and relative to "root". (Closed) Base URL: https://chromium.googlesource.com/chromium/blink.git@master

Patch Set: Code review. Improved comment. Use will-change where possible. Created 6 years, 2 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« LayoutTests/fast/multicol/composited-relpos-clipped.html ('K') | « LayoutTests/fast/multicol/composited-relpos-expected.html ('k') | LayoutTests/fast/multicol/composited-with-child-layer-in-next-column-expected.html » ('j') | Source/core/rendering/RenderLayer.cpp » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 <!DOCTYPE html>

	2 <p>There should be a yellow box in the second column, and the word 'PASS' should be in the third column.</p>

	3 <div style="-webkit-columns:3; column-fill:auto; height:9em; line-height:2em;">

	4 <div style="will-change:transform; position:absolute; left:0; right:0; heigh t:9em; background:cyan;"></div>
	Julien - ping for review 2014/10/13 19:25:02 Ditto. Ditto.
	5 <br>

	6 <br>

	7 <br>

	8 <br>

	9 <br>

	10 <br>

	11 <br>

	12 <div style="z-index:2; position:relative; height:2em; background:yellow;">

	13 <br>

	14 <br>

	15 <div style="opacity:0.8; margin:0.5em;">PASS</div>

	16 </div>

	17 </div>
	Julien - ping for review 2014/10/13 19:25:02 I am concerned about these tests that seems very f I am concerned about these tests that seems very fragile to me as both are relying on the multi-column to work (ie if it's broken, it's going to be broken in the same way). mstensho (USE GERRIT) 2014/10/13 20:47:25 If multicol is THAT broken, surely we already have Show quoted text On 2014/10/13 19:25:02, Julien Chaffraix - PST wrote: > I am concerned about these tests that seems very fragile to me as both are > relying on the multi-column to work (ie if it's broken, it's going to be broken > in the same way). If multicol is THAT broken, surely we already have more basic tests to catch that? But if you prefer, I could make the refs not use multicol at all. Julien - ping for review 2014/10/14 18:28:07 You're making an assumption (that we have enough b Show quoted text On 2014/10/13 20:47:25, mstensho wrote: > On 2014/10/13 19:25:02, Julien Chaffraix - PST wrote: > > I am concerned about these tests that seems very fragile to me as both are > > relying on the multi-column to work (ie if it's broken, it's going to be > broken > > in the same way). > > If multicol is THAT broken, surely we already have more basic tests to catch > that? You're making an assumption (that we have enough basic testing) but it seems that none of us knows if that's the case, which makes me very uneasy. The difference between the tests and their expected files are minimal meaning that it's easy for both to be broken in the same way IMO. That's why my slight paranoia asks for some guarantees that we don't just land tests that can mask / ignore real failures. mstensho (USE GERRIT) 2014/10/14 19:32:10 Done. Let's take no chances and avoid multicol in Show quoted text On 2014/10/14 18:28:07, Julien Chaffraix - PST wrote: > On 2014/10/13 20:47:25, mstensho wrote: > > On 2014/10/13 19:25:02, Julien Chaffraix - PST wrote: > > > I am concerned about these tests that seems very fragile to me as both are > > > relying on the multi-column to work (ie if it's broken, it's going to be > > broken > > > in the same way). > > > > If multicol is THAT broken, surely we already have more basic tests to catch > > that? > > You're making an assumption (that we have enough basic testing) but it seems > that none of us knows if that's the case, which makes me very uneasy. The > difference between the tests and their expected files are minimal meaning that > it's easy for both to be broken in the same way IMO. That's why my slight > paranoia asks for some guarantees that we don't just land tests that can mask / > ignore real failures. Done. Let's take no chances and avoid multicol in the refs. :)
OLD	NEW