Another Acid 3 Fix: Ranges and Document Mutation
Posted by Darin Adler on Saturday, March 15th, 2008 at 9:27 amYou probably know that the Acid 3 score for nightly builds of WebKit was 90/100 last week. Today it’s up to 91/100 because I fixed our handling of DOM ranges under document mutation.
In older versions of WebKit, if you removed the node at one end of a DOM range from the document, the range would end up with one endpoint in the document and another endpoint outside the document. Ranges aren’t supposed to work that way. Instead, when you modify the document the range is supposed to get “fixed up” so that both endpoints are still in the document.
That’s fixed now and so Acid 3 test 13 now passes. See bug 11997 if you want to know more of the details.
March 15th, 2008 at 10:34 am
As other commenters pointed out in the previous post, current WK builds are rather flaky when running the Acid3 test.
Case in point, I downloaded today’s build (31055) and loaded the acid3 test site immediately. The first time it ran, it briefly paused at 64% and moved up to 89. I hit reload and it went straight up, to 88. Then after 5 seconds or so I hit reload again and it then stalled at 64% – it was waiting for something to load – and then WK crashed.
top of stackdump;
Thread 0 Crashed:
0 ??? 0000000000 0 + 0
1 com.apple.WebCore 0×00f46d61 WebCore::SubresourceLoader::didFinishLoading() + 49
2 com.apple.Foundation 0×9090d8b7 -[NSURLConnection(NSURLConnectionReallyInternal) sendDidFinishLoading] + 87
3 com.apple.Foundation 0×9090d844 _NSURLConnectionDidFinishLoading + 68
running on Mac OS X 10.5.2, MBP rev. 1.
About these types of crashes in WK, is it useful to file bug reports for crashes like these that may be gone the next build? I guess if a crash should be reproducible over a number of builds before it should be reported as a real bug? Sorry if all of this is obvious, my brain is out of phazon.
March 15th, 2008 at 11:29 am
From what you’ve pasted, it looks like you’re hitting Bug 17860 .
Reproducible crashes should always be reported, whether they occur over multiple builds or not. Even if you’re not sure whether something is a bug or not, it’s better to report it and have someone with more insight to investigate it, than to not have it reported at all.
March 16th, 2008 at 5:37 am
Same as xfinite. Except that I got pretty unstable test results - varying from 88 to 91.
March 16th, 2008 at 7:03 am
The first time I tried, I got 86, now every time I get 87… I don’t know what’s going on there…
March 16th, 2008 at 12:29 pm
Folks, if you see results other than 91/100, please write a bug report. We need specifics, like what platform you’re running WebKit on.
Blog comments aren’t good places for bug reports — we don’t track them or anything.
March 16th, 2008 at 2:24 pm
darin, everyone seems to get results other than 91 occasionally. I used to get 88, 89 and 90 randomly before the most recent fix. I now almost always get 91, but just managed to get 89 on the latest build, with test 78 failing (expected 90 got 0 - getRotationOfChar(0) failed) and test 77 failing (expected 4776 but got 5550 - getComputedTextLength failed).
Is there already an open bug I can contribute anything to?
March 16th, 2008 at 2:27 pm
Oh, and I’m on Safari 3.0.4, WebKit r31084 on OS X 10.5.2.
March 16th, 2008 at 4:50 pm
@eAi: Please file a new bug report and include the information that you mentioned.
March 16th, 2008 at 4:56 pm
eAi: details of your hardware and network setup would be helpful, in a bug report. I would suggest filing a new one at http://bugs.webkit.org, it is not very complicated to file a bug and if it is a duplicate we can relate it.