[EFL] Fix the build with EFL 1.12
https://bugs.webkit.org/show_bug.cgi?id=138245

Reviewed by Gyuyoung Kim.

Source/WebKit2:

* UIProcess/API/efl/EwkView.cpp:
First, modified to use Evas_GL raw pointer instead of UniquePtrEfl because
Evas_GL.h can't be included in UniquePtrEfl.h
It should be moved into EvasGLContext because WebKit/EFL use only one Evas_GL.
Second, provided the version of GLES in Evas_GL_Config not to break build with
EFL 1.12
(EwkView::EwkView):
(EwkView::~EwkView):
(EwkView::displayTimerFired):
(EwkView::createGLSurface):
* UIProcess/API/efl/EwkView.h:

Source/WTF:

* wtf/efl/UniquePtrEfl.h:
Removed Evas_GL.h from UniquePtrEfl.h, which is commonly included, because
it should not be included with official GL headers.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176066 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed GTK gardening. Skip more test failing after r175776.

* platform/gtk/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176068 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Lazily create HTMLInputElement's inputType and shadow subtree
https://bugs.webkit.org/show_bug.cgi?id=138524

Reviewed by Ryosuke Niwa.

Source/WebCore:

When an HTMLInputElement was created by the parser, we would first call
HTMLInputElement::create(), then call Element::parserSetAttributes() on
the constructed input. With the previous implementation, this was a bit
inefficient because HTMLInputElement::create() would construct a
TextInputType inputType (as this is the default) as well as its
corresponding shadow subtree. Then, parserSetAttributes() would often
set the |type| attribute and would need to destroy this input type as
well as its subtree if the new |type| is not 'text', to create a new
inputType / shadow subtree of the right type. The profiler showed that
this was fairly expensive.

To improve this, this patch delays the inputType / shadow subtree
creation when the HTMLInputElement is constructed by the parser, until
the attributes are actually set by the parser. This way, we directly
create an inputType / shadow subtree of the right type.

I see a 1.4% speed up on speedometer (73.95 -> 75.0).

Test: fast/dom/HTMLInputElement/border-attribute-crash.html

* dom/Element.cpp:
(WebCore::Element::parserSetAttributes):
(WebCore::Element::parserDidSetAttributes):
* dom/Element.h:
* html/HTMLInputElement.cpp:
(WebCore::HTMLInputElement::HTMLInputElement):
(WebCore::HTMLInputElement::create):
(WebCore::HTMLInputElement::updateType):
(WebCore::HTMLInputElement::runPostTypeUpdateTasks):
(WebCore::HTMLInputElement::initializeInputType):
(WebCore::HTMLInputElement::parseAttribute):
(WebCore::HTMLInputElement::parserDidSetAttributes):
(WebCore::HTMLInputElement::finishParsingChildren):
* html/HTMLInputElement.h:

LayoutTests:

Add a test case to make sure we don't crash when parsing an <input>
Element that has a |border| attribute as first attribute. This is what
was happening with the first version of this patch that landed in
r175852. When attributeChanged() was called for the |border| attribute
HTMLInputElement::isPresentationAttribute() would get called before
m_inputType is initialized, and "name == borderAttr && isImageButton()"
would crash because isImageButton() dereferences m_inputType.

* fast/dom/HTMLInputElement/border-attribute-crash-expected.txt: Added.
* fast/dom/HTMLInputElement/border-attribute-crash.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@176069 268f45cc-cd09-0410-ab3c-d52691b4dbfc