Bug 213303 – REGRESSION (r263098): [Win10] http/tests/security/cross-origin-clean-css-resource-timing.html and http/tests/security/cross-origin-css-resource-timing.html are failing

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Ryan Haddad]

http/tests/security/cross-origin-clean-css-resource-timing.html and http/tests/security/cross-origin-css-resource-timing.html are consistently failing on Win10 bots:

--- /home/buildbot/worker/win10-release-tests/build/layout-test-results/http/tests/security/cross-origin-clean-css-resource-timing-expected.txt
+++ /home/buildbot/worker/win10-release-tests/build/layout-test-results/http/tests/security/cross-origin-clean-css-resource-timing-actual.txt
@@ -1,3 +1,4 @@
+CONSOLE MESSAGE: Unhandled Promise Rejection: Error: assert_false: image expected false got true
 
-PASS CSS subresources of a clean stylesheet should populate resource timing entries, but not for imported stylesheets 
+FAIL CSS subresources of a clean stylesheet should populate resource timing entries, but not for imported stylesheets assert_false: image expected false got true
 

--- /home/buildbot/worker/win10-release-tests/build/layout-test-results/http/tests/security/cross-origin-css-resource-timing-expected.txt
+++ /home/buildbot/worker/win10-release-tests/build/layout-test-results/http/tests/security/cross-origin-css-resource-timing-actual.txt
@@ -1,3 +1,5 @@
+CONSOLE MESSAGE: Unhandled Promise Rejection: Error: assert_false: import expected false got true
+Test
 
-PASS CSS subresources of an opaque stylesheet should not populate resource timing entries 
+FAIL CSS subresources of an opaque stylesheet should not populate resource timing entries assert_false: import expected false got true
 
https://results.webkit.org/?suite=layout-tests&suite=layout-tests&test=http%2Ftests%2Fsecurity%2Fcross-origin-clean-css-resource-timing.html&test=http%2Ftests%2Fsecurity%2Fcross-origin-css-resource-timing.html

[Radar WebKit Bug Importer]

<rdar://problem/64452203>

[Ryan Haddad]

Test history suggests that this regressed with https://trac.webkit.org/changeset/263098/webkit

[Ryan Haddad]

Youenn says he will look at this tomorrow.

[Ryan Haddad]

Marked tests as failing to keep EWS moving quickly in the interim.

[Ryan Haddad]

(In reply to Ryan Haddad from comment #4)
> Marked tests as failing to keep EWS moving quickly in the interim.
http://trac.webkit.org/r263162

[youenn fablet]

Created attachment 402199 [details]
Patch

[youenn fablet]

Test seem to pass in windows by reverting a change that was not mandatory for https://trac.webkit.org/changeset/263098/webkit.
I am not quite sure why and we should probably get back to it at some point.

[Alex Christensen]

Comment on attachment 402199 [details]
Patch

If this fixes it, I don't oppose.  Definitely strange.

[EWS]

Committed r263218: <https://trac.webkit.org/changeset/263218>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 402199 [details].

[Darin Adler]

Comment on attachment 402199 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=402199&action=review

> Source/WebCore/loader/ResourceLoaderOptions.h:145
> -enum class LoadedFromOpaqueSource : bool {
> -    No,
> -    Yes
> +enum class LoadedFromOpaqueSource : uint8_t {
> +    Yes,
> +    No
>  };

If this value is sent cross process with Encoder/Decoder, changing from bool to uint8_t might require specializing EnumTraits. So it might be slightly trickier than just reverting. I see no test failures, I guess this is not done with this enumeration?

[youenn fablet]

(In reply to Alex Christensen from comment #8)
> Comment on attachment 402199 [details]
> Patch
> 
> If this fixes it, I don't oppose.  Definitely strange.

This fixes it according the bots.

> If this value is sent cross process with Encoder/Decoder, changing from bool
> to uint8_t might require specializing EnumTraits. So it might be slightly
> trickier than just reverting. I see no test failures, I guess this is not
> done with this enumeration?

Issue is WK1 and I do not think this is encoder/decoder.
Maybe this is Windows compiler specific.