Crash in WebCore::RenderBlock::removeChild
https://bugs.webkit.org/show_bug.cgi?id=93879

Patch by Raul Hudea <rhudea@adobe.com> on 2012-08-22
Reviewed by Abhishek Arya.

Source/WebCore:

By adding the lifetime state to the RenderNamedFlowThread (r122556), it become possible for the a RenderRegion object to delete its sibling,
the RenderNamedFlowThread. This is unexpected in the rendering world and cause problems in RenderBlock::removeChild where we retain previous
and next sibling pointers.
So, all the RenderNamedFlowThread are created under a RenderFlowThreadContainer object insted of the RenderView. The new object is created only
when the first named flow is created.

Test: fast/regions/remove-flow-thread-crash.html

* CMakeLists.txt:
* GNUmakefile.list.am:
* Target.pri:
* WebCore.gypi:
* WebCore.vcproj/WebCore.vcproj:
* WebCore.xcodeproj/project.pbxproj:
* rendering/FlowThreadController.cpp:
(WebCore::FlowThreadController::FlowThreadController): Added initialization for the new RenderFlowThreadContainer member
(WebCore::FlowThreadController::ensureRenderFlowThreadWithName): Added the creation of the RenderFlowThreadContainer object and use it as a parent for all RenderNamedFlowThreads
(WebCore::FlowThreadController::styleDidChange): Inform all the RenderNamedFlowThreads that the style changed in regions (initially this code was in RenderView, but now all RenderNamedFlowThreads are children of RenderFlowThreadContainer)
(WebCore):
* rendering/FlowThreadController.h:
(WebCore):
(FlowThreadController):
* rendering/RenderFlowThreadContainer.cpp: Added.
(WebCore):
(WebCore::RenderFlowThreadContainer::RenderFlowThreadContainer):
(WebCore::RenderFlowThreadContainer::layout):
* rendering/RenderFlowThreadContainer.h: Added.
* rendering/RenderObject.cpp:
(WebCore::RenderObject::markContainingBlocksForLayout): Skip to RenderView if the current object is an RenderFlowThreadContainer.
* rendering/RenderObject.h:
(WebCore::RenderObject::isRenderFlowThreadContainer):
* rendering/RenderView.cpp:
(WebCore::RenderView::styleDidChange): Moved the code associated to RenderNamedFlowThreads to FlowThreadController:styleDidChange and call it instead.

LayoutTests:

Test the region-flow_thread sibling case

* fast/regions/remove-flow-thread-crash-expected.txt: Added.
* fast/regions/remove-flow-thread-crash.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126304 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Build failures with harfbuzz outside standard locations
https://bugs.webkit.org/show_bug.cgi?id=93030

Reviewed by Rob Buis.

Add ${HARFBUZZ_INCLUDE_DIRS} to the list of included paths: so far
it was being implicitly pulled from evas's pkg-config file, and
used to work when WebKit-EFL's dependencies were built with
jhbuild -- in this case, harfbuzz is built before evas, which is
then built with harfbuzz support and adds the required paths to
its .pc file.

We need to include things directly to account for the case of
people not using jhbuild and thus not necessarily having harfbuzz
as an evas dependency.

* PlatformEfl.cmake:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126305 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Split WebCore/platform into a separate library
https://bugs.webkit.org/show_bug.cgi?id=94435

Reviewed by Martin Robinson.

More people have been reporting problems when linking WebCore because
the command line limit is being exceeded. Splitting WebCore a bit more
is in order.

.:

* GNUmakefile.am: add variable that will hold the list of source files
for libWebCorePlatform .

Source/WebCore:

* GNUmakefile.am: add new libWebCorePlatform convenience library.
* GNUmakefile.list.am: move list of platform/* files to its own variable.

Source/WebKit/gtk:

* GNUmakefile.am: link libWebCorePlatform into libwebkitgtk

Source/WebKit2:

* GNUmakefile.am: link libWebCorePlatform into libwebkit2gtk

Tools:

* GNUmakefile.am: link libWebCorePlatform into DRT

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126306 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Crash when finalizing WebKitWebView
https://bugs.webkit.org/show_bug.cgi?id=94699

Reviewed by Martin Robinson.

Create the offscreen window the first time accelerated compositing
is enabled, so that if it's never enabled the window won't be
created.

* WebCoreSupport/AcceleratedCompositingContextGL.cpp:
(WebKit::AcceleratedCompositingContext::AcceleratedCompositingContext):
(WebKit::AcceleratedCompositingContext::initialize):
(WebKit::AcceleratedCompositingContext::setRootCompositingLayer):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126307 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: [WebGL] Support the communication protocol from the injected script
https://bugs.webkit.org/show_bug.cgi?id=94689

Patch by Andrey Adaikin <aandrey@chromium.org> on 2012-08-22
Reviewed by Pavel Feldman.

Support the WebGL communication protocol from the injected script module.

* inspector/InjectedScriptWebGLModuleSource.js:
(.):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126308 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r125710): accessibility/accessibility-node-reparent.html, accessibility/accessibility-node-memory-management.html failing on GTK Linux
https://bugs.webkit.org/show_bug.cgi?id=94200

Reviewed by Chris Fleizach.

Tools:

Adds reference counting for AtkObjects referenced by
AccessibilityUIElementGtk. This prevents bogus results and
assertion failures on AccessibilityUIElements whose underlying
object has been deleted (as opposed to just made defunct).

This fixes two tests that were previously failing because of this bug.

* DumpRenderTree/gtk/AccessibilityUIElementGtk.cpp:
(AccessibilityUIElement::AccessibilityUIElement):
(AccessibilityUIElement::~AccessibilityUIElement):

LayoutTests:

This patch fixes two tests and removes them from gtk expectations.

* platform/gtk/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126309 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION(r125578): fast/regex/unicodeCaseInsensitive.html crash on Linux Debug Chromium
https://bugs.webkit.org/show_bug.cgi?id=94010

Reviewed by Tony Chang.

r125578 inspected the raw text run for word-end but the index it used to do so was for a normalized
version of the run that could be longer than the raw text run. So to allow proper detection of word-end
in complex text (i) do not normalize tabs to plain white-space and (ii) go back to using the normalized version
of the run for detecting word-end. There is a risk that some fonts may create glyphs for the '\t' character
but this does not turn up in any of our regression tests and the more common risk appears to be the new-line.

Test: fast/regex/unicodeCaseInsensitive.html

* platform/graphics/harfbuzz/HarfBuzzShaperBase.cpp:
(WebCore::normalizeSpacesAndMirrorChars):


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