WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
153772
[GTK] [EFL] [AppleWin] Layout Test fast/shadow-dom/slot-removal-crash-2.html timeouts
https://bugs.webkit.org/show_bug.cgi?id=153772
Summary
[GTK] [EFL] [AppleWin] Layout Test fast/shadow-dom/slot-removal-crash-2.html ...
Carlos Alberto Lopez Perez
Reported
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.
Attachments
Fixes the test
(1.23 KB, patch)
2016-02-01 15:58 PST
,
Ryosuke Niwa
mcatanzaro
: review+
buildbot
: commit-queue-
Details
Formatted Diff
Diff
Archive of layout-test-results from ews116 for mac-yosemite
(901.81 KB, application/zip)
2016-02-01 17:38 PST
,
Build Bot
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2016-02-01 15:58:47 PST
Created
attachment 270442
[details]
Fixes the test
Carlos Alberto Lopez Perez
Comment 2
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
Carlos Alberto Lopez Perez
Comment 3
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.
Build Bot
Comment 4
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
Build Bot
Comment 5
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
Ryosuke Niwa
Comment 6
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.
Michael Catanzaro
Comment 7
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?
Ryosuke Niwa
Comment 8
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
.
Ryosuke Niwa
Comment 9
2016-02-01 18:35:16 PST
Committed
r196000
: <
http://trac.webkit.org/changeset/196000
>
Romain Bellessort
Comment 10
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?
Carlos Garcia Campos
Comment 11
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.
Romain Bellessort
Comment 12
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
).
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug