Bug 62754 – http/tests/misc/object-embedding-svg-delayed-size-negotiation-2.htm fails

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: CSS

[Stephen White]

The following (new) layout tests are giving incorrect pixel results on Chromium after WebKit r88913:

WIN LINUX : css2.1/20110323/block-non-replaced-width-008.htm = IMAGE+TEXT
- big red square visible (should be no red)
WIN LINUX : css2.1/20110323/block-replaced-width-001.htm = IMAGE+TEXT *
- blue box is offset from the orange box
WIN LINUX : css2.1/20110323/replaced-elements-001.htm = IMAGE+TEXT
- orange box should be horizontally centered; are left-justified
WIN LINUX : css2.1/20110323/replaced-intrinsic-ratio-001.htm = IMAGE+TEXT
- should have six blue squares; only four are visible (the rest would probably be visible except the window is too small)

The pixel results on Safari/mac are wrong as well, except for the *'ed test above, which is only incorrect on Chromium.  The rest of the new test results seem to be ok.

[Nikolas Zimmermann]

Are you saying the baselines in platform/mac/ are wrong for some of these tests?
I manually checked all pngs before checking them in, and did a comparision run with and without my patch, and found no regressions.

Did I misunderstand you and only Chromium sees errors?

[Stephen White]

(In reply to comment #1)
> Are you saying the baselines in platform/mac/ are wrong for some of these tests?

Yes, for 3 of the 4 tests -- the other one is failing only on Chrome (two squares are supposed to be horizontally centered, but are slightly offset from each other).

> I manually checked all pngs before checking them in, and did a comparision run with and without my patch, and found no regressions.
> 
> Did I misunderstand you and only Chromium sees errors?

No, I think the checked-in platform/mac results are wrong for 3 of the tests (although I could be wrong).

[Nikolas Zimmermann]

(In reply to comment #0)
> The following (new) layout tests are giving incorrect pixel results on Chromium after WebKit r88913:
> 
> WIN LINUX : css2.1/20110323/block-non-replaced-width-008.htm = IMAGE+TEXT
> - big red square visible (should be no red)
> WIN LINUX : css2.1/20110323/block-replaced-width-001.htm = IMAGE+TEXT *
> - blue box is offset from the orange box
> WIN LINUX : css2.1/20110323/replaced-elements-001.htm = IMAGE+TEXT
> - orange box should be horizontally centered; are left-justified
> WIN LINUX : css2.1/20110323/replaced-intrinsic-ratio-001.htm = IMAGE+TEXT
> - should have six blue squares; only four are visible (the rest would probably be visible except the window is too small)
> 
> The pixel results on Safari/mac are wrong as well, except for the *'ed test above, which is only incorrect on Chromium.  The rest of the new test results seem to be ok.

I've verified these tests on a trunk build on SnowLeopard.
1. replaced-intrinsic-ratio-001.htm
It has six blue squares, it's just that the DRT dump doesn't show all of them as the size of the document is larger than the 800x600 (at least in height). If you manually run it, you'll see all of them work fine.
This test also has duplicates in svg/zoom/page/zoom-replaced-intrinsic-ratio-001.htm which zooms the test out 4 times, so that the full output (6 blue squares) fits into the DRT dumped image, so that's covered as well.

2. block-replaced-width-001.htm
Works just fine for me? No offset: the orange box is right above the blue box, no gaps.

3. block-non-replaced-width-008.htm
As reported in the original bug report (15849) this is still failing. It failed before my patch and still fails now, as its unrelated to the intrinsic sizing work.

4. replaced-elements-001.htm
Good catch, but I just checked it was broken before as well. I forgot to mention it in the bug report 15849, where I added these tests.

Can you confirm Chromium behaves the same, or does it still have a chromium specific bug on any of those?

[Stephen White]

Hi Nikolas,

First off, just wanted to say that I didn't mean to accuse your patch of breaking anything.  These (new?) tests are almost all passing which is awesome.  I just needed a bug # to put in our test_expectations file for those which aren't passing, and I thought I'd CC you in case you had any insight.

(In reply to comment #3)
> (In reply to comment #0)
> > The following (new) layout tests are giving incorrect pixel results on Chromium after WebKit r88913:
> > 
> > WIN LINUX : css2.1/20110323/block-non-replaced-width-008.htm = IMAGE+TEXT
> > - big red square visible (should be no red)
> > WIN LINUX : css2.1/20110323/block-replaced-width-001.htm = IMAGE+TEXT *
> > - blue box is offset from the orange box
> > WIN LINUX : css2.1/20110323/replaced-elements-001.htm = IMAGE+TEXT
> > - orange box should be horizontally centered; are left-justified
> > WIN LINUX : css2.1/20110323/replaced-intrinsic-ratio-001.htm = IMAGE+TEXT
> > - should have six blue squares; only four are visible (the rest would probably be visible except the window is too small)
> > 
> > The pixel results on Safari/mac are wrong as well, except for the *'ed test above, which is only incorrect on Chromium.  The rest of the new test results seem to be ok.
> 
> I've verified these tests on a trunk build on SnowLeopard.
> 1. replaced-intrinsic-ratio-001.htm
> It has six blue squares, it's just that the DRT dump doesn't show all of them as the size of the document is larger than the 800x600 (at least in height). If you manually run it, you'll see all of them work fine.

Yeah, that's what I said in my comment above.  I guess we can check in a truncated version for Chrome too.

> This test also has duplicates in svg/zoom/page/zoom-replaced-intrinsic-ratio-001.htm which zooms the test out 4 times, so that the full output (6 blue squares) fits into the DRT dumped image, so that's covered as well.

OK, cool.

> 2. block-replaced-width-001.htm
> Works just fine for me? No offset: the orange box is right above the blue box, no gaps.

Yes, this one is Chrome-only (orange square is offset by a pixel or so).  Probably a Skia issue, since it doesn't affect Chrome/Mac.

> 3. block-non-replaced-width-008.htm
> As reported in the original bug report (15849) this is still failing. It failed before my patch and still fails now, as its unrelated to the intrinsic sizing work.
> 
> 4. replaced-elements-001.htm
> Good catch, but I just checked it was broken before as well. I forgot to mention it in the bug report 15849, where I added these tests.
> 
> Can you confirm Chromium behaves the same, or does it still have a chromium specific bug on any of those?

Just the 2nd one.  Thanks for taking a look.

[Peter Kasting]

This is now about one test, http/tests/misc/object-embedding-svg-delayed-size-negotiation-2.htm , which times out on Linux release and (on the canaries) Mac release.

[Peter Kasting]

I oversimplified.  This test times out in some configurations and gets IMAGE+TEXT failures in others.