[Webkit-unassigned] [Bug 66295] [Meta] Support w3c reftests

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Nov 3 09:36:45 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=66295





--- Comment #11 from Hayato Ito <hayato at chromium.org>  2011-11-03 09:36:45 PST ---
(In reply to comment #9)
> We could probably get away with only reading the file to look for the links if the don't find a text (or audio) baseline. In addition, it looks like the WG is recommending that the reference files be named as -ref.html or -notref.html, so we could check for the existence of those filenames as well and only parse the file looking for a link as a last resort.

In order to minimize the startup time of collecting tests, we should try to avoid parsing HTML files as few as possible in this phase. Lets discuss using examples. Suppose a directory contains the following files:

- a.html
- a-expected.txt
- a-expected.png
- b.html
- b-expected.html
- c.html
- c-ref.html
- d.html
- d-notref.html

In this case, it is easy to know which files are w3c reftests without parsing, c.html and d.html.

But I am afraid that every w3c reftests won't follow this name convention. And remember that w3c reftests can have multiple reference files per a test. In that case, it might be more difficult to detect w3c reftests and reference files without parsing. Suppose the following more complicated case:

- a.html
  <link rel="match" href="common-ref.html" />
- b.html
  <link rel="match" href="common-ref.html" />
- c.html
  <link rel="match" href="common-ref.html" />
- d.html
  <link rel="match" href="d-1-ref.html" />
  <link rel="match" href="d-2-ref.html" />
- d-1-ref.html
- d-2-ref.html
- common-ref.html

In this case, we somehow should parse the HTML files.
So my suggestion is:

1. At first, use a heuristic rule as soon as possible and eliminate html files which are easily detected.
2. For remaining files, parse the content to know whether this html file is w3 reftest or not.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list