Bug 67251 - Chromium defines its own toHTMLInputElement in DOMUtilitiesPrivate.h
Summary: Chromium defines its own toHTMLInputElement in DOMUtilitiesPrivate.h
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-30 18:47 PDT by Ryosuke Niwa
Modified: 2013-04-11 15:12 PDT (History)
6 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2011-08-30 18:47:28 PDT 
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).
Comment 1 Darin Fisher (:fishd, Google) 2011-08-30 22:22:46 PDT 
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.