<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_REOPENED "
   title="REOPENED - Many of the expected results from imported/w3c are wrong (contain FAIL strings)"
   href="https://bugs.webkit.org/show_bug.cgi?id=161003#c7">Comment # 7</a>
              on <a class="bz_bug_link 
          bz_status_REOPENED "
   title="REOPENED - Many of the expected results from imported/w3c are wrong (contain FAIL strings)"
   href="https://bugs.webkit.org/show_bug.cgi?id=161003">bug 161003</a>
              from <span class="vcard"><a class="email" href="mailto:youennf&#64;gmail.com" title="youenn fablet &lt;youennf&#64;gmail.com&gt;"> <span class="fn">youenn fablet</span></a>
</span></b>
        <pre><span class="quote">&gt; Sometimes when dealing with old official test suites (like DOM2), a failure
&gt; result on a subtest is the correct one, due to a change in newer spec
&gt; version, so we don't even want to &quot;fix&quot; it. Yet we do want to run the test,
&gt; to make sure that we don't start crashing, or that we don't accidentally
&gt; revert to old behavior, and of course to verify other subtests in the test.</span >

I guess that in such a case, it is ok to change the test since we are no longer tracking it from a remote source. In an ideal world, changing the test so that FAIL disappears from the expectations files would be nice.
But this is probably a low priority.

I created <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [Mac] Rebase some failing XMLHttpRequest tests"
   href="show_bug.cgi?id=161036">bug 161036</a> to create Mac specific expectations for those tests.
It seems ok to me to have the &quot;best&quot; expectation files as the generic baseline.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>