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.
Still occuring for me on r31446.
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.
> 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).
I can reproduce this consistently on ToT.
*** Bug 18225 has been marked as a duplicate of this bug. ***
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.
*** Bug 23002 has been marked as a duplicate of this bug. ***
*** Bug 22984 has been marked as a duplicate of this bug. ***
*** Bug 23169 has been marked as a duplicate of this bug. ***
*** Bug 23383 has been marked as a duplicate of this bug. ***
<rdar://problem/6504899>
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.
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.
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.
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.
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.
Fixed in r40278.