Bug 112094

Summary: [Chromium] Embedder should be able to define built-in like custom elements
Product: WebKit Reporter: Hajime Morrita <morrita>
Component: DOMAssignee: Hajime Morrita <morrita>
Status: RESOLVED WONTFIX    
Severity: Normal CC: abarth, cmarcelo, dglazkov, esprehn+autocc, fishd, jamesr, japhet, ojan.autocc, schenney, tkent+wkapi, webcomponents-bugzilla, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 110436    
Bug Blocks: 99688    
Attachments:
Description Flags
Patch
none
Patch abarth: review-

Hajime Morrita
Reported 2013-03-11 19:19:55 PDT
Some embedder-provided tags like <webview> want be custom elements, which - have non-hyphen names - make their shadows non-traversable
Attachments
Patch (8.82 KB, patch)
2013-03-12 01:02 PDT, Hajime Morrita
no flags
Patch (8.82 KB, patch)
2013-03-14 03:07 PDT, Hajime Morrita
abarth: review-
Hajime Morrita
Comment 1 2013-03-12 01:02:04 PDT
WebKit Review Bot
Comment 2 2013-03-12 01:04:40 PDT
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.
Adam Barth
Comment 3 2013-03-12 11:30:59 PDT
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&
Adam Barth
Comment 4 2013-03-12 11:31:44 PDT
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?
Hajime Morrita
Comment 5 2013-03-14 03:07:13 PDT
Hajime Morrita
Comment 6 2013-03-14 03:09:58 PDT
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.
Adam Barth
Comment 7 2013-03-15 12:24:32 PDT
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?
Adam Barth
Comment 8 2013-03-15 12:26:42 PDT
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.
Hajime Morrita
Comment 9 2013-03-15 23:44:16 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.