Some embedder-provided tags like <webview> want be custom elements, which - have non-hyphen names - make their shadows non-traversable
Created attachment 192661 [details] Patch
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Comment on attachment 192661 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=192661&action=review > Source/WebCore/loader/FrameLoaderClient.h:374 > + virtual bool isUserAgentCustomElementName(String /*name*/) { return false; } String -> const String& > Source/WebKit/chromium/public/WebFrameClient.h:438 > + virtual bool isUserAgentCustomElementName(WebFrame*, WebString) { return false; } WebString -> const WebString&
Is it better to call out from WebKit to the embedder, as you've done in this patch, or to have the embedder configure this information into WebKit?
Created attachment 193097 [details] Patch
Adam, thanks for looking this responsibly! I updated the patch. > Is it better to call out from WebKit to the embedder, as you've done in this patch, or to have the embedder configure this information into WebKit? This is my first plan. But I notice that - it's a tricky business for embedder to track Document lifetime precisely and give appropriate element name for each newly created element. - Chromium API layer has no extra strage associated to Document lifetime. So I switched to this "pull" approach.
Comment on attachment 193097 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=193097&action=review > Source/WebKit/chromium/public/WebFrameClient.h:433 > + // Asks whether given element name is used as a embedder-providing > + // custom element. Such custom elements can have names without hyphen, > + // and their shadow trees aren't traversable. > + virtual bool isUserAgentCustomElementName(WebFrame*, const WebString&) { return false; } How does this behave when we create an element in a document that is no longer active in a frame? I guess we don't make the callback and therefore the element types disappear?
Comment on attachment 193097 [details] Patch I don't think we should do this yet. We should wait until the custom element mechanism is more mature before exposing it to the embedder. Otherwise, we'll make it difficult for ourselves to track the spec as it evolves because we'll have a constraint that other browser engines won't have.
(In reply to comment #8) > (From update of attachment 193097 [details]) > I don't think we should do this yet. We should wait until the custom element mechanism is more mature before exposing it to the embedder. Otherwise, we'll make it difficult for ourselves to track the spec as it evolves because we'll have a constraint that other browser engines won't have. Adam, thanks for your feedback. The point is valid. I'd discuss the team to search other possible approaches.