Bug 193521 – Unreviewed GTK and WPE test gardening.

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Alicia Boya García]

.

[Alicia Boya García]

Created attachment 359338 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 359338 [details]
Patch for landing

Clearing flags on attachment: 359338

Committed r240102: <https://trac.webkit.org/changeset/240102>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Michael Catanzaro]

This caused imported/w3c/web-platform-tests/fetch/security/dangling-markup-mitigation-data-url.tentative.sub.html to begin unexpectedly failing. It had never failed before on the GTK release bot. I've deleted the added expectation.

It also caused fast/events/touch/emulate-touch-events.html to begin unexpectedly passing. I've removed the failure expectation, since it never failed before on the GTK release bot. (Why did you point it at bug #173419?)

[Alicia Boya García]

(In reply to Michael Catanzaro from comment #4)
> This caused
> imported/w3c/web-platform-tests/fetch/security/dangling-markup-mitigation-
> data-url.tentative.sub.html to begin unexpectedly failing. It had never
> failed before on the GTK release bot. I've deleted the added expectation.

Why though? Did you checked the diff? Was there a paste error or is it flaky?

> It also caused fast/events/touch/emulate-touch-events.html to begin
> unexpectedly passing. I've removed the failure expectation, since it never
> failed before on the GTK release bot. (Why did you point it at bug #173419?)

Hmmm... It fails in Debug only it seems. I pointed to #173419 because it was already pointing there in WPE, along with many other fast/events/ failures.

[Michael Catanzaro]

(In reply to Alicia Boya García from comment #5)
> (In reply to Michael Catanzaro from comment #4)
> > This caused
> > imported/w3c/web-platform-tests/fetch/security/dangling-markup-mitigation-
> > data-url.tentative.sub.html to begin unexpectedly failing. It had never
> > failed before on the GTK release bot. I've deleted the added expectation.
> 
> Why though? Did you checked the diff? Was there a paste error or is it flaky?

The test had never failed on the release bot before you added the expectation, and it's passing again now that I've removed the expectation. Do you remember why you added the expectation?

> > It also caused fast/events/touch/emulate-touch-events.html to begin
> > unexpectedly passing. I've removed the failure expectation, since it never
> > failed before on the GTK release bot. (Why did you point it at bug #173419?)
> 
> Hmmm... It fails in Debug only it seems. I pointed to #173419 because it was
> already pointing there in WPE, along with many other fast/events/ failures.

That bug looks unrelated (and WPE-specific). So it should use a [ Debug ] expectation and have a new bug.

[Alicia Boya García]

(In reply to Michael Catanzaro from comment #6)
> (In reply to Alicia Boya García from comment #5)
> > (In reply to Michael Catanzaro from comment #4)
> > > This caused
> > > imported/w3c/web-platform-tests/fetch/security/dangling-markup-mitigation-
> > > data-url.tentative.sub.html to begin unexpectedly failing. It had never
> > > failed before on the GTK release bot. I've deleted the added expectation.
> > 
> > Why though? Did you checked the diff? Was there a paste error or is it flaky?
> 
> The test had never failed on the release bot before you added the
> expectation, and it's passing again now that I've removed the expectation.
> Do you remember why you added the expectation?

Because the diff was a FAIL line being replaced with PASS, so I assumed it needed a rebaseline.

--- /home/slave/webkitgtk/gtk-linux-64-debug-tests/build/layout-test-results/imported/w3c/web-platform-tests/fetch/security/dangling-markup-mitigation-data-url.tentative.sub-expected.txt
+++ /home/slave/webkitgtk/gtk-linux-64-debug-tests/build/layout-test-results/imported/w3c/web-platform-tests/fetch/security/dangling-markup-mitigation-data-url.tentative.sub-actual.txt
@@ -2,7 +2,7 @@
 
 PASS <img id="dangling" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII="> 
 FAIL <img id="dangling" src="data:image/png;base64,&#10;iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII="> assert_equals: Height expected 1 but got 0
-FAIL <img id="dangling" src="data:image/png;base64,i&#10;VBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII="> assert_equals: Height expected 1 but got 0
+PASS <img id="dangling" src="data:image/png;base64,i&#10;VBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII="> 
 PASS <img id="dangling" src="data:image/svg+xml;utf8,\n      <svg width='1' height='1' xmlns='http://www.w3.org/2000/svg'>\n        <rect width='100%' height='100%' fill='rebeccapurple'/>\n        <rect x='10%' y='10%' width='80%' height='80%' fill='lightgreen'/>\n      </svg>"> 
 PASS <iframe id="dangling"\n        src="data:text/html,\n            <img\n              onload='window.parent.postMessage(&quot;loaded&quot;, &quot;*&quot;);'\n              onerror='window.parent.postMessage(&quot;error&quot;, &quot;*&quot;);'\n              src='http://localhost:8800/images/gr&#10;een-256x256.png'>\n        ">\n     </iframe> 
 PASS <iframe id="dangling"\n        src="data:text/html,\n            <img\n              onload='window.parent.postMessage(&quot;loaded&quot;, &quot;*&quot;);'\n              onerror='window.parent.postMessage(&quot;error&quot;, &quot;*&quot;);'\n              src='http://localhost:8800/images/green-256x256.png?&lt;'>\n        ">\n     </iframe>

[Michael Catanzaro]

Where are you seeing the PASS in the actual result? Can you link to results on build.webkit.org so I can understand, please?