Bug 67251 – Chromium defines its own toHTMLInputElement in DOMUtilitiesPrivate.h

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit Misc.

[Ryosuke Niwa]

Apparently chromium defines its own toHTMLInputElement in DOMUtilitiesPrivate.h, and this caused compilation to fail after I landed http://trac.webkit.org/changeset/94142.

Error messages:
Source/WebKit/chromium/src/EditorClientImpl.cpp: In member function ‘virtual void WebKit::EditorClientImpl::textFieldDidEndEditing(WebCore::Element*)’:
Source/WebKit/chromium/src/EditorClientImpl.cpp:657: error: call of overloaded ‘toHTMLInputElement(WebCore::Element*&)’ is ambiguous
Source/WebKit/chromium/src/DOMUtilitiesPrivate.h:49: note: candidates are: WebCore::HTMLInputElement* WebKit::toHTMLInputElement(WebCore::Node*)
Source/WebCore/html/HTMLInputElement.h:359: note:                 WebCore::HTMLInputElement* WebCore::toHTMLInputElement(WebCore::Node*)

Source/WebKit/chromium/src/EditorClientImpl.cpp: In member function ‘virtual bool WebKit::EditorClientImpl::doTextFieldCommandFromEvent(WebCore::Element*, WebCore::KeyboardEvent*)’:
Source/WebKit/chromium/src/EditorClientImpl.cpp:679: error: call of overloaded ‘toHTMLInputElement(WebCore::Element*&)’ is ambiguous
Source/WebKit/chromium/src/DOMUtilitiesPrivate.h:49: note: candidates are: WebCore::HTMLInputElement* WebKit::toHTMLInputElement(WebCore::Node*)

It's very error-prone for each port to define utility functions that act on WebCore objects like this.  At least, we shouldn't have WebCore::toHTMLInputElement and WebKit::toHTMLInputElement that have two different behaviors (the latter returns null when the node's tagName isn't inputTag).

[Darin Fisher (:fishd, Google)]

It seems like we should be able to kill WebKit::toHTMLInputElement.  If you want to just rename the functions in DOMUtilitiesPrivate.h as a stop-gap measure, that would be fine.

[Stephen Chenney]

https://code.google.com/p/chromium/issues/detail?id=230618