Bug 179031 – Add some WebKitAdditions extension points to WebCore

• Status: RESOLVED
• Resolution: INVALID
• Component: WebCore Misc.

[Daniel Bates]

Add some WebKitAdditions extension points to WebCore.

[Radar WebKit Bug Importer]

<rdar://problem/35259516>

[Daniel Bates]

Created attachment 325415 [details]
Patch

With regards to the processing of the HTML tag names .in files I debated between teaching make_names.pl to accept multiple --tag files and having DerivedSources.make concatenate all the .in files before generating the HTML tag names. This patch takes the latter approach. I chose this approach because the former would require solving how makes_names.pl would handle more than one namespace, namespacePrefix, namespaceURI, and fallbackJSInterfaceName keys (as each .in file could define them). Maybe it would be sufficient to error out if all the specified files did not have the same values for these keys? Maybe make_names.pl should have command line options to specify values for these keys and then assume all --tag files use the same namespace? For now I opted to avoid these questions and concatenate the existing html/HTMLTagNames.in and any additional .in files (in that order) before passing to make_names.pl as I'm unclear how useful and long lasting this extension point is/will be. Let me know if it would be better to fix up makes_names.pl and ideas for solving the concatenation order/multiple namespace issue.

[Daniel Bates]

(In reply to Daniel Bates from comment #2)
> Created attachment 325415 [details]
> Patch
> 
> With regards to the processing of the HTML tag names .in files I debated
> between teaching make_names.pl to accept multiple --tag files and having
> DerivedSources.make concatenate all the .in files before generating the HTML
> tag names. This patch takes the latter approach. I chose this approach
> because the former would require solving how makes_names.pl would handle
> more than one namespace, namespacePrefix, namespaceURI, and
> fallbackJSInterfaceName keys (as each .in file could define them). Maybe it
> would be sufficient to error out if all the specified files did not have the
> same values for these keys? Maybe make_names.pl should have command line
> options to specify values for these keys and then assume all --tag files use
> the same namespace? For now I opted to avoid these questions and concatenate
> the existing html/HTMLTagNames.in and any additional .in files (in that
> order) before passing to make_names.pl as I'm unclear how useful and long
> lasting this extension point is/will be. Let me know if it would be better
> to fix up makes_names.pl and ideas for solving the concatenation
> order/multiple namespace issue.

s|makes_names.pl|Source/WebCore/dom/make_names.pl|g

[Daniel Bates]

As it turns out it is no longer necessary to make these changes.