I accidentally uploaded and landed my patch for the bug 148850 in the bug 154936, so here's a new bug to actually fix the bug 154936 was intended to fix.
<rdar://problem/24944875>
Created attachment 272734 [details] Fixes the bug
Created attachment 272736 [details] Fixed debug builds
Created attachment 272738 [details] Updated the bug title
I don't think the Windows EWS failure is related to this patch.
Comment on attachment 272738 [details] Updated the bug title View in context: https://bugs.webkit.org/attachment.cgi?id=272738&action=review > Source/WebCore/bindings/js/JSDocumentCustom.cpp:155 > + ExceptionCodeWithMessage ec; > + ec.code = NOT_SUPPORTED_ERR; > + ec.message = "Cannot define a custom element in template content's document"; > + setDOMException(&state, ec); > + return jsUndefined(); Isn’t here a helper function that does more of this? If not, we should make one. The helper function should be written so that this code reads more like this: return throwNotSupportedException(state, "Cannot define a custom element in template content's document"); > Source/WebCore/dom/CustomElementDefinitions.h:51 > + static Ref<CustomElementDefinitions> create() { return adoptRef(*new CustomElementDefinitions()); } You can omit those parentheses. > Source/WebCore/dom/Document.cpp:6359 > + ASSERT(!m_customElementDefinitions); Do we also want to assert document.m_customElementDefinitions is non-null?
Created attachment 272789 [details] Address Darin's comment and updated per recent discussion on Github
We realized that we can't share the registry with window-less document either so we're forbidding that as well.
Committed r197528: <http://trac.webkit.org/changeset/197528>