Bug 153772

Summary: [GTK] [EFL] [AppleWin] Layout Test fast/shadow-dom/slot-removal-crash-2.html timeouts
Product: WebKit Reporter: Carlos Alberto Lopez Perez <clopez>
Component: WebKitGTKAssignee: Ryosuke Niwa <rniwa>
Status: RESOLVED FIXED    
Severity: Normal CC: bugs-noreply, cdumez, cgarcia, kling, koivisto, mcatanzaro, rniwa, romain.wkt
Priority: P2    
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Fixes the test
mcatanzaro: review+, buildbot: commit-queue-
Archive of layout-test-results from ews116 for mac-yosemite none

Description Carlos Alberto Lopez Perez 2016-02-01 15:27:51 PST
The following layout test is timing out on platforms GTK+, EFL and AppleWin since it was added on r195727 <http://trac.webkit.org/r195727>

Regressions: Unexpected timeouts (1)
  fast/shadow-dom/slot-removal-crash-2.html [ Timeout ]

https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#tests=fast%2Fshadow-dom%2Fslot-removal-crash-2.html

Probable cause: unknown.
Comment 1 Ryosuke Niwa 2016-02-01 15:58:47 PST
Created attachment 270442 [details]
Fixes the test
Comment 2 Carlos Alberto Lopez Perez 2016-02-01 16:06:11 PST
I have updated the GTK+, EFL and AppleWin expectations regarding this test on http://trac.webkit.org/changeset/195986
Comment 3 Carlos Alberto Lopez Perez 2016-02-01 16:07:31 PST
(In reply to comment #1)
> Created attachment 270442 [details]
> Fixes the test

I have just tested this patch on the GTK+ port.

The test not longer timeouts, but now it fails with the following text:

-- /home/clopez/webkit/webkit/layout-test-results/fast/shadow-dom/slot-removal-crash-2-expected.txt
+++ /home/clopez/webkit/webkit/layout-test-results/fast/shadow-dom/slot-removal-crash-2-actual.txt
@@ -1,5 +1,5 @@
+CONSOLE MESSAGE: line 23: TypeError: host.attachShadow is not a function. (In 'host.attachShadow({mode: 'open'})', 'host.attachShadow' is undefined)
 Test that removing a slot element with text node does not result in an assertion failure.
 The test passes if WebKit does not hit an assertion.
-PASS.
Comment 4 Build Bot 2016-02-01 17:38:09 PST
Comment on attachment 270442 [details]
Fixes the test

Attachment 270442 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/770055

New failing tests:
imported/w3c/web-platform-tests/streams-api/readable-streams/garbage-collection-1.html
Comment 5 Build Bot 2016-02-01 17:38:11 PST
Created attachment 270458 [details]
Archive of layout-test-results from ews116 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews116  Port: mac-yosemite  Platform: Mac OS X 10.10.5
Comment 6 Ryosuke Niwa 2016-02-01 17:51:10 PST
(In reply to comment #3)
> (In reply to comment #1)
> > Created attachment 270442 [details]
> > Fixes the test
> 
> I have just tested this patch on the GTK+ port.
> 
> The test not longer timeouts, but now it fails with the following text:
> 
> --
> /home/clopez/webkit/webkit/layout-test-results/fast/shadow-dom/slot-removal-
> crash-2-expected.txt
> +++
> /home/clopez/webkit/webkit/layout-test-results/fast/shadow-dom/slot-removal-
> crash-2-actual.txt
> @@ -1,5 +1,5 @@
> +CONSOLE MESSAGE: line 23: TypeError: host.attachShadow is not a function.
> (In 'host.attachShadow({mode: 'open'})', 'host.attachShadow' is undefined)
>  Test that removing a slot element with text node does not result in an
> assertion failure.
>  The test passes if WebKit does not hit an assertion.
> -PASS.

That's expected because shadow DOM API isn't enabled on GTK+ port.
Comment 7 Michael Catanzaro 2016-02-01 17:59:53 PST
It's OFF by default in WebKitFeatures.cmake, and in FeatureList.pm it's enabled only for Mac and iOS.

I suspect this is a mistake; is there a reason it should not be enabled by default? Why is it a build option at all?
Comment 8 Ryosuke Niwa 2016-02-01 18:05:30 PST
(In reply to comment #7)
> It's OFF by default in WebKitFeatures.cmake, and in FeatureList.pm it's
> enabled only for Mac and iOS.
> 
> I suspect this is a mistake; is there a reason it should not be enabled by
> default? Why is it a build option at all?

The feature wasn't / isn't ready for production use.  You can follow the progress on https://bugs.webkit.org/show_bug.cgi?id=148695.
Comment 9 Ryosuke Niwa 2016-02-01 18:35:16 PST
Committed r196000: <http://trac.webkit.org/changeset/196000>
Comment 10 Romain Bellessort 2016-06-13 01:00:36 PDT
I found an XMLHttpRequest test that fails with GTK due to the missing support of shadow DOM. When enabled, the test passes, and so do all fast/shadow-dom tests that pass on Mac. Would it make sense to enable shadow DOM for GTK by default or is it still too early?
Comment 11 Carlos Garcia Campos 2016-06-13 01:05:10 PDT
(In reply to comment #10)
> I found an XMLHttpRequest test that fails with GTK due to the missing
> support of shadow DOM. When enabled, the test passes, and so do all
> fast/shadow-dom tests that pass on Mac. Would it make sense to enable shadow
> DOM for GTK by default or is it still too early?

I think we can enable it in GTK+ now.
Comment 12 Romain Bellessort 2016-06-13 02:32:03 PDT
(In reply to comment #11)
> (In reply to comment #10)
> > I found an XMLHttpRequest test that fails with GTK due to the missing
> > support of shadow DOM. When enabled, the test passes, and so do all
> > fast/shadow-dom tests that pass on Mac. Would it make sense to enable shadow
> > DOM for GTK by default or is it still too early?
> 
> I think we can enable it in GTK+ now.

Thanks for the response. I just submitted a bug and will soon provide a patch (https://bugs.webkit.org/show_bug.cgi?id=158686).