Status: Untriaged
Owner: [email protected]
Labels: Type-Bug Pri-2 OS-All Area-Misc LayoutTests

New issue 24192 by [email protected]: Update chrome/http tests with  
accurate "expected results"
http://code.google.com/p/chromium/issues/detail?id=24192


pkasting on September 11 2007 15:07
(Assigned)
Summary
    chrome/http tests do not use HTTP server
Component
    Chrome > Deprecated > Tools > Layout Tests
Reporter
    pkasting
Assignee
    sridharg
CC
    chrome-bugs
Type
    Bug
Priority
    P2
Severity
    S2
In prod
    false
Notes
These tests are all failing:

chrome\http\mime\iframe_NULL.html
chrome\http\mime\iframe_application_x-shockwave-flash.html
chrome\http\mime\iframe_image_bmp.html
chrome\http\mime\iframe_image_gif.html
chrome\http\mime\iframe_image_jpg.html
chrome\http\mime\iframe_image_png.html
chrome\http\mime\iframe_image_tif.html
chrome\http\mime\iframe_text _html.html

I think this is because they're not actually being served by the http
server, and they need to be in order to work properly (they have perl
scripts which autogenerate some of their content via GET queries).

The problem here is that the http server is running with a document root in
http/tests, which is not an ancestor of chrome/http, so there's no way for
the server to serve these documents.

Several possible fixes:
* Start two instances of the http server, on different ports, with the two
different document roots.
* Start one instance, which listens on two ports and has a different
document root on each one (might be tricky).
* Only run one instance of the http server at a time, with a different
document root depending on what the test wants (probably harder and slower
than the above options).
* Move the tests in chrome/http into http/tests/chrome, and update all the
relevant checkout/compare/etc. scripts to know that we added these files
and they don't come from Apple (easy but potentially leads to confusion
down the road).
pamg on September 11 2007 15:28
(Assigned)
Assignee
    pamg
Notes
The goal is to submit these to Apple and move them into http/tests/.  See
WebKit bug http://bugs.webkit.org/show_bug.cgi?id=15031 .  That's on my
plate now that Preetham's internship ended, but work is on hold pending
verification of the expected results by abarth (or someone) -- it's not
clear to me what we *should* be doing in many of these cases.

In the meantime, we should just ignore these tests.  Since we're not sure
what we ought to expect, they're not yet useful.
pkasting on September 11 2007 16:16
(Assigned)
Notes
OK, but we should distinguish between "we're ignoring these because our
framework isn't running them correctly" and "we're ignoring these because
we're not sure what the expected results should be".  It sounds like both
reasons are true right now, and I guess this bug covers both?
pkasting on September 11 2007 16:29
(Assigned)
Summary
    Update chrome/http tests with accurate "expected results"
Assignee
    abarth
Notes
After discussion with pamg, I'm morping this bug to be about examining the
tests and figuring out what their expected results ought to be.  Once
that's done, we can submit to Apple in the aforementioned WebKit bug, and
once _that's_ done, these will show up in a location where the normal test
server will be.

In the meantime, I am going to ignore all these tests, as there is no point
in running them.

Pam said that Adam had agreed to look at this (as a low-priority task), so
assigning to him; it should go back to pamg if he doesn't get to it.
abarth on September 20 2007 17:20
(New)
Assignee
    <none>
Notes
These tests could use some improvement.

1) The tests don't seem to cover the missing Content-Type case, which is
quite important.
2) The tests don't cover the cases that confuse IE, namely content that
correctly parses as multiple types.
3) The tests cover TIF images, which we don't support.

I didn't have time to look at all the cases, but we were doing the
"correct" thing in the cases I did look at.  There isn't an objective
"correct" behavior on these tests.  I wish I had more time to go through
these.  What might make sense to enable them (and baseline them to our
current behavior) so we can track if our behavior changes.  Unassigning due
to lack of time.
mal on November 05 2007 10:25
(New)
Hotlist
    chrome-layout-test-bugs, WebKit ignored tests
pamg on December 12 2007 12:11
(New)
CC
    chrome-bugs, pamg
pamg on December 12 2007 13:11
(New)
Notes
The httpd DocumentRoot issue has been fixed: tests in
layout_tests/chrome/http are now run via a local http server.

The need to figure out what the right expected results are for these tests
and to cover additional cases still remains.  They're still skipped.
eseidel on March 13 2008 17:54
(New)
Hotlist
    chrome-layout-test-bugs, WebKit ignored tests, layout_test_failures
pkasting on April 10 2008 16:44
( migrated from http://buganizer/issue?id=849072 )

(New)
Hotlist
    chrome-layout-test-bugs, WebKit ignored tests, layout_test_failures,
Cr__Rel_Future, Cr__Untriaged
mal on July 18 2008 21:43
(New)
Hotlist
    chrome-layout-test-bugs, WebKit ignored tests, layout_test_failures,
Cr__Rel_Future
sridharg on September 12 2008 10:53
(New)
Hotlist
    WebKit ignored tests, layout_test_failures, Cr__Rel_Future


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---

Reply via email to