|Summary:||[chromium] http/tests/loading/preload-append-scan.php fails|
|Product:||WebKit||Reporter:||Tony Gentilcore <tonyg>|
|Component:||WebKit Misc.||Assignee:||Tony Gentilcore <tonyg>|
|Severity:||Normal||CC:||commit-queue, koivisto, tkent|
|Version:||528+ (Nightly build)|
|OS:||OS X 10.5|
|Bug Depends on:|
Description Tony Gentilcore 2011-04-12 11:30:29 PDT
http/tests/loading/preload-append-scan.php was introduced by http/tests/loading/preload-append-scan.php. It fails on chromium with an extra line at at top: main frame - didFinishDocumentLoadForFrame Filed in chromium as http://crbug.com/79006
Comment 1 Tony Gentilcore 2011-04-12 11:54:04 PDT
The first comment should have said "...introduced by http://trac.webkit.org/changeset/83321"
Comment 2 Tony Gentilcore 2011-04-12 12:37:05 PDT
It looks like whichever test runs after http/tests/loading/onload-vs-immediate-refresh.pl will have the extra didFinishDocumentLoadForFrame. I'm looking into a fix.
Comment 3 Tony Gentilcore 2011-04-12 12:42:26 PDT
Yep, previously preload-img-test followed the offending test and it is skipped in chromium w/ this note: // Extra didFinishDocumentLoadForFrame line. // The first didFinishDocumentLoadForFrame line is for the previous test documen\ t. BUG_DRT WIN MAC LINUX : http/tests/loading/preload-img-test.html = TEXT TIMEOUT \ PASS
Comment 5 Kent Tamura 2011-04-12 16:27:32 PDT
Comment on attachment 89257 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=89257&action=review > LayoutTests/ChangeLog:10 > + On chromium, onload-vs-immediate-refresh always caused the subsequent test to fail > + with an additional difFinishLoadForFrame message. This was because the test > + navigates via a refresh, but did not actually wait for the navigation to complete. difFinishLoadForFrame -> didFinishLoadForFrame Can we fix Chromium DRT?
Comment 6 Tony Gentilcore 2011-04-12 16:36:21 PDT
> difFinishLoadForFrame -> didFinishLoadForFrame Oops, I'll fix and land. > Can we fix Chromium DRT? Do you understand what needs to be fixed (if anything)? If the test doesn't call waitUntilDone, DRT can finish at the first yield. I'm guessing the mac port never yields since it navigates to a data URL which might be synchronous (but I haven't verified). I guess the question is how event messages can ever leak to the next test.
Comment 7 Tony Gentilcore 2011-04-12 16:37:00 PDT
Created attachment 89305 [details] Patch for landing
Comment 8 WebKit Commit Bot 2011-04-12 20:49:31 PDT
Comment on attachment 89305 [details] Patch for landing Rejecting attachment 89305 [details] from commit-queue. Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=cr-jail-8', 'build-..." exit_code: 2 Last 500 characters of output: s/fileapi . http/tests/globalhistory .... http/tests/history ............................. http/tests/incremental ...... http/tests/inspector-enabled ... http/tests/inspector ........... http/tests/inspector/network .. http/tests/loading ............. http/tests/loading/onload-vs-immediate-refresh.pl -> failed Exiting early after 1 failures. 22284 tests run. 587.22s total testing time 22283 test cases (99%) succeeded 1 test case (<1%) had incorrect layout 13 test cases (<1%) had stderr output Full output: http://queues.webkit.org/results/8400143
Comment 9 WebKit Commit Bot 2011-04-12 20:49:35 PDT
Created attachment 89332 [details] Archive of layout-test-results from cr-jail-8 The attached test failures were seen while running run-webkit-tests on the commit-queue. Bot: cr-jail-8 Port: Mac Platform: Mac OS X 10.6.6
Comment 10 Tony Gentilcore 2011-04-13 13:00:59 PDT
Created attachment 89440 [details] Patch for landing
Comment 11 WebKit Commit Bot 2011-04-14 01:27:30 PDT
Comment on attachment 89440 [details] Patch for landing Clearing flags on attachment: 89440 Committed r83823: <http://trac.webkit.org/changeset/83823>
Comment 12 WebKit Commit Bot 2011-04-14 01:27:35 PDT
All reviewed patches have been landed. Closing bug.