Bug 18141 - Acid3 tests 77 and 78 fail on reload (for some people, not everyone)
Summary: Acid3 tests 77 and 78 fail on reload (for some people, not everyone)
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Major
Assignee: Nobody
URL: http://acid3.acidtests.org
Keywords: InRadar, NeedsReduction
: 18225 22984 23002 23169 23383 (view as bug list)
Depends on:
Blocks: Acid3
  Show dependency treegraph
 
Reported: 2008-03-27 04:22 PDT by Michael Ward
Modified: 2009-01-26 16:45 PST (History)
8 users (show)

See Also:


Attachments
Test case (982 bytes, text/plain)
2009-01-22 16:11 PST, Sam Weinig
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Ward 2008-03-27 04:22:17 PDT
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.
Comment 1 zealotzuo 2008-03-27 22:40:47 PDT
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.
Comment 2 Michael Ward 2008-03-31 02:59:39 PDT
Still occuring for me on r31446.
Comment 3 Michael Ward 2008-04-03 23:59:02 PDT
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.
Comment 4 François Lamboley 2008-04-16 08:50:15 PDT
> 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).
Comment 5 Ismail Donmez 2008-06-30 12:11:39 PDT
I can reproduce this consistently on ToT.
Comment 6 Alexey Proskuryakov 2008-07-18 07:58:53 PDT
*** Bug 18225 has been marked as a duplicate of this bug. ***
Comment 7 Mark J. Hughes 2008-12-18 14:31:17 PST
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.
Comment 8 Alexey Proskuryakov 2009-01-02 11:11:50 PST
*** Bug 23002 has been marked as a duplicate of this bug. ***
Comment 9 Alexey Proskuryakov 2009-01-02 11:12:03 PST
*** Bug 22984 has been marked as a duplicate of this bug. ***
Comment 10 Alexey Proskuryakov 2009-01-08 09:01:32 PST
*** Bug 23169 has been marked as a duplicate of this bug. ***
Comment 11 Mark Rowe (bdash) 2009-01-16 22:31:15 PST
*** Bug 23383 has been marked as a duplicate of this bug. ***
Comment 12 Mark Rowe (bdash) 2009-01-16 22:31:34 PST
<rdar://problem/6504899>
Comment 13 Sam Weinig 2009-01-20 13:58:29 PST
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.
Comment 14 Sam Weinig 2009-01-20 14:31:07 PST
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.
Comment 15 Sam Weinig 2009-01-20 22:55:02 PST
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.
Comment 16 Sam Weinig 2009-01-22 16:11:31 PST
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.
Comment 17 Sam Weinig 2009-01-22 16:16:31 PST
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.
Comment 18 Sam Weinig 2009-01-26 16:45:59 PST
Fixed in r40278.