media/track/track-remove-track.html is flaky. It was this way since the test was added last week. http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=media%2Ftrack%2Ftrack-remove-track.html Crash: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.WebCore 0x00000001126cf84c WebCore::createWrapperInline(JSC::ExecState*, WebCore::JSDOMGlobalObject*, WebCore::Node*) + 156 (JSNodeCustom.cpp:202) 1 com.apple.WebCore 0x00000001126cf795 WebCore::createWrapper(JSC::ExecState*, WebCore::JSDOMGlobalObject*, WebCore::Node*) + 37 (JSNodeCustom.cpp:253) 2 com.apple.WebCore 0x0000000111bc0b55 WebCore::toJS(JSC::ExecState*, WebCore::JSDOMGlobalObject*, WebCore::Node*) + 133 (JSNodeCustom.h:47) 3 com.apple.WebCore 0x0000000111fcdeef WebCore::HTMLMediaElement::didAddUserAgentShadowRoot(WebCore::ShadowRoot*) + 447 (HTMLMediaElement.cpp:5963) Fail: @@ -1,4 +1,2 @@ -PASS Tests that the 'removetrack' event is fired when an out-of-band TextTrack is removed. -PASS Tests that the 'removetrack' event is NOT fired for inband TextTrack on a failed load. - +Harness Error. harness_status.status = 2 , harness_status.message = null
Marked as flaky in <http://trac.webkit.org/r166508>.
On GTK this test times out, but if you run it with a high enough timeout it gives this very same failure. I'll update the GTK test expectations for this test to point here also.
Created attachment 274777 [details] Proposed patch.
Comment on attachment 274777 [details] Proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=274777&action=review > Source/WebCore/html/HTMLMediaElement.cpp:3890 > + Ref<HTMLMediaElement> protect(*this); // Loading and running script can trigger GC. > + ensureUserAgentShadowRoot(); This is not our usual idiom for protect. It's better to add a Ref[Ptr] to a function that needs to use a pointer after an operation that could destroy it. ensureMediaControlsShadowRoot is clearly not such a function, because it doesn't do anything after calling ensureUserAgentShadowRoot().
Comment on attachment 274777 [details] Proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=274777&action=review > Source/WebCore/ChangeLog:9 > + No new tests, this fixes an existing test. Is the test still marked as flaky or failing in TestExpectations?
Created attachment 275050 [details] Proposed patch.
Attachment 275050 [details] did not pass style-queue: ERROR: Source/WebCore/html/HTMLMediaElement.cpp:192: preprocessor directives (e.g., #ifdef, #define, #import) should never be indented. [whitespace/indent] [4] ERROR: Source/WebCore/html/HTMLMediaElement.cpp:193: Multi line control clauses should use braces. [whitespace/braces] [4] Total errors found: 2 in 4 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 275050 [details] Proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=275050&action=review > Source/WebCore/html/HTMLMediaElement.cpp:192 > + #define CASE(actionType) \ Please #undef this at the end. > Source/WebCore/html/HTMLMediaElement.cpp:199 > + CASE(HTMLMediaElementEnums::LoadMediaResource); It's probably better to log without the prefix. > Source/WebCore/html/HTMLMediaElement.cpp:409 > + , m_haveSetupCaptionContainer(false) I think that WebKit style for this is m_haveSetUpCaptionContainer. > Source/WebCore/html/HTMLMediaElement.cpp:3911 > + m_creatingControls = true; Should we ASSERT(!m_creatingControls) here?
Created attachment 275091 [details] Patch for landing.
Comment on attachment 275091 [details] Patch for landing. Clearing flags on attachment: 275091 Committed r198780: <http://trac.webkit.org/changeset/198780>
All reviewed patches have been landed. Closing bug.