Bug 18141 – Acid3 tests 77 and 78 fail on reload (for some people, not everyone)

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Michael Ward]

Using r31368 on Windows XP using Safari 3.1, Acid3 test passes at 100/100 on the first load, however, after using Ctrl+R to reload the page, tests 77+78 both fail.

The following errors are reported:

Test 77 failed: expected '4776' but got '5550' - getComputedTextLengthFailed
Test 78 failes: expected '90' but got '0' - getRotationOfChar(0) failed.

Using r31381 and Mac OS X 10.5, tests 77 and 78 fail even without reloading. A few of my friends have confirmed this too.

[Michael Ward]

Still occuring for me on r31446.

[Michael Ward]

Webkit still seems to be leaving itself in an unreliable state after the acid3 test passes once.

Using build r31446, I managed to get 100/100, reloaded and got 99/100 (test 77 failed, same as above) and then I got 98/100 with the same two fails as reported above.

After the closing the browser, i got 100/100 then 98/100 with the same two fails.

[François Lamboley]

> Using r31381 and Mac OS X 10.5, tests 77 and 78 fail even without reloading. A
> few of my friends have confirmed this too.

I have exactly the same problem (iMac 2.8GHz Intel Core 2 Duo under leopard (10.5.2))
The test 80 fails too (kungFuDeathGrip was null).
The tests fail each time I launch the acid test (after a cache clean, the 80 succeeded).

[Ismail Donmez]

I can reproduce this consistently on ToT.

[Alexey Proskuryakov]

*** Bug 18225 has been marked as a duplicate of this bug. ***

[Mark J. Hughes]

FWIW - I noticed this for the first time today, though I don't believe I'd seen it previously. Running the most recent nightly r39370 on Mac OS X 10.5.5:

Failed 2 tests.
Test 77 failed: expected '4776' but got '5550' - getComputedTextLength failed.
Test 78 failed: expected '90' but got '0' - getRotationOfChar(0) failed.
Total elapsed time: 1.03s

Not sure if there is any other info that could be useful.

[Alexey Proskuryakov]

*** Bug 23002 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

*** Bug 22984 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

*** Bug 23169 has been marked as a duplicate of this bug. ***

[Mark Rowe (bdash)]

*** Bug 23383 has been marked as a duplicate of this bug. ***

[Mark Rowe (bdash)]

<rdar://problem/6504899>

[Sam Weinig]

I am not able to reproduce this.  Does anyone who has been able to reproduce this have any extensions installed?  That would be really valuable information.

[Sam Weinig]

Scratch that. I can now intermittently reproduce without any extensions.  Seems like this probably an issue with Font loading, I will try to prove/disprove that.

[Sam Weinig]

The issue seems to be that we are firing onload for an iframe containing an external reference to an SVGFont before the font has loaded.  This is due to our current design lazily loading SVGFonts upon first use.

[Sam Weinig]

Created attachment 26943 [details]
Test case

To try this test case, apply the patch to your tree, run run-webkit-httpd and go to http://127.0.0.1:8000/test.html.  If you see an alert with the text "loaded", the test has failed.

[Sam Weinig]

I don't think it is clear that the onload event should be delayed for the SVGFont.  The SVG spec says that the SVGLoad event is not delayed unless externalResourcesRequired is specified.  I am not sure what its impact on the onload handler is though.

[Sam Weinig]

Fixed in r40278.