[EFL][WK2] PageUIClientEfl should keep in sync with WKPageUIClient
https://bugs.webkit.org/show_bug.cgi?id=107060

Patch by Jaehun Lim <ljaehun.lim@samsung.com> on 2013-01-16
Reviewed by Benjamin Poulain.

Rearrange the order of functions in PageUIClientEfl.
Rename closePage() to close().

* UIProcess/API/efl/EwkViewImpl.cpp:
(EwkViewImpl::close):
* UIProcess/API/efl/EwkViewImpl.h:
(EwkViewImpl):
* UIProcess/efl/PageUIClientEfl.cpp:
(WebKit::PageUIClientEfl::PageUIClientEfl):
(WebKit::PageUIClientEfl::close):
(WebKit::PageUIClientEfl::takeFocus):
(WebKit::PageUIClientEfl::focus):
(WebKit::PageUIClientEfl::unfocus):
(WebKit::PageUIClientEfl::getWindowFrame):
(WebKit::PageUIClientEfl::setWindowFrame):
(WebKit::PageUIClientEfl::createNewPage):
(WebKit::PageUIClientEfl::showColorPicker):
(WebKit::PageUIClientEfl::hideColorPicker):
* UIProcess/efl/PageUIClientEfl.h:
(PageUIClientEfl):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139937 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Teach HTMLParserOptions about Settings::threadedHTMLParser
https://bugs.webkit.org/show_bug.cgi?id=107068

Reviewed by Tony Gentilcore.

We use this option to enable the threaded HTML parser at runtime.

* html/parser/HTMLParserOptions.cpp:
(WebCore::HTMLParserOptions::HTMLParserOptions):
* html/parser/HTMLParserOptions.h:
(HTMLParserOptions):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139938 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Cursor stops blinking after clicking on scrollbar
https://bugs.webkit.org/show_bug.cgi?id=106470

Reviewed by Ojan Vafai.

Restore the caret blinking when doing a mouseup on a
scrollbar so scrolling a textarea doesn't cause the
caret to freeze.

No new tests, there doesn't seem to be any way to test
cursor blinking.

* page/EventHandler.cpp:
(WebCore::EventHandler::handleMouseReleaseEvent):
(WebCore::EventHandler::handleMouseDoubleClickEvent):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139939 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge RenderObjectChildList::appendChildNode and insertChildNode
https://bugs.webkit.org/show_bug.cgi?id=106392

Reviewed by Eric Seidel.

insertChildNode and appendChildNode are nearly identical methods and
we can combine them into insertChildNode and handle cases where the
renderer to insert before is null as if it was an append.

No new tests, just refactoring.

* rendering/RenderObjectChildList.cpp:
(WebCore::RenderObjectChildList::insertChildNode):
* rendering/RenderObjectChildList.h:
(RenderObjectChildList):
(WebCore::RenderObjectChildList::appendChildNode):
    Now inline and delegates to insertChildNode.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139940 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix mac build system warnings introduced by r139866
https://bugs.webkit.org/show_bug.cgi?id=107056

Patch by Pablo Flouret <pablof@motorola.com> on 2013-01-16
Reviewed by Benjamin Poulain.

warning: no rule to process file '$(PROJECT_DIR)/css/CSSSupportsRule.h' of type sourcecode.c.h for architecture x86_64
warning: no rule to process file '$(BUILT_PRODUCTS_DIR)/DerivedSources/WebCore/JSCSSSupportsRule.h' of type sourcecode.c.h for architecture x86_64

{JS,}CSSSupportsRule.h somehow ended up marked as sources in the XCode
project.

No new tests. Build warning fix.

* WebCore.xcodeproj/project.pbxproj:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139941 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WebCore::ScriptRunner::timerFired() is reported to crash.
https://bugs.webkit.org/show_bug.cgi?id=92211

Reviewed by Darin Adler.

This is a speculative fix to address some crash reports.
Here is my rough guess.

The crash report says there is a PendingScript instance whose m_element is null.
- It happens only if the instance is created through the default constructor,
- that could happen if m_pendingAsyncScripts doesn't contains matched PendingScript in ScriptRunner::notifyScriptReady(),
- that could happen when notifyScriptReady() is called more than once.
- It turns out that the call site, ScriptElement::notifyFinished(), could be called multiple times since
  it doesn't remove itself from the CachedResource, which is done separately in ScriptElement::execute().
- So if notifyFinished() is called before execute(), it could happen

This change added a guard to prevent notifyFinished() from being invoked multiple times.
We should watch if these crash reports disappear.

No new tests. I couldn't create any repro for this.

* dom/ScriptElement.cpp:
(WebCore::ScriptElement::notifyFinished):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139942 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix crash when destroying a plug-in with pending URL requests
https://bugs.webkit.org/show_bug.cgi?id=107075
<rdar://problem/12513871>

Reviewed by Sam Weinig.

In PluginView::destroyPluginAndReset, make sure to cancel any outstanding URL requests since the PluginView
object will stay around and would otherwise start loading URLs from stopped plug-ins.

* WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::Stream::start):
Assert that the plug-in is alive.

(WebKit::PluginView::destroyPluginAndReset):
Empty out the pending URL requests vector and stop the timer.

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