[CSS Regions] Destroying a render named flow thread without unregistering left-over content nodes triggered an assertion.
https://bugs.webkit.org/show_bug.cgi?id=95645

Patch by Andrei Bucur <abucur@adobe.com> on 2012-09-04
Reviewed by Abhishek Arya.

Source/WebCore:

This patch cleans up the render named flow thread before destruction by unregistering left-over content nodes.

Tests: fast/regions/moved-content-node-crash.html

* rendering/RenderNamedFlowThread.cpp:
(WebCore::RenderNamedFlowThread::~RenderNamedFlowThread):

LayoutTests:

Simple test case that triggers an ASSERT in debug mode and causes a crash in release.
The ASSERT appears in RenderFlowThreadController::unregisterNamedFlowContentNode
ASSERT(it != m_mapNamedFlowContentNodes.end());

It happens because when a content node is added to an iframe document and then moved back, the iframe's RenderNamedFlowThread is destroyed
without calling unregisterNamedFlowContentNode on the node. This triggers the before mentioned assertion after a lazyAttach and a detach
in the parent document.

* fast/regions/moved-content-node-crash-expected.txt: Added.
* fast/regions/moved-content-node-crash.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127472 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Allow asyncronous response of pointer lock requests in layout tests.
https://bugs.webkit.org/show_bug.cgi?id=95628

Reviewed by James Robinson.

Tools:

Future tests need the ability to respond asynchronously that
pointer lock requests have been accepted or rejected. This patch
adds the following:
    testRunner.setPointerLockWillRespondAsynchronously();
    testRunner.didAcquirePointerLock();
    testRunner.didNotAcquirePointerLock();

Tested in existing test:
    pointerlockchange-pointerlockerror-events.html

* DumpRenderTree/chromium/DRTTestRunner.cpp:
(DRTTestRunner::DRTTestRunner):
(DRTTestRunner::didAcquirePointerLock):
(DRTTestRunner::didNotAcquirePointerLock):
(DRTTestRunner::setPointerLockWillRespondAsynchronously):
* DumpRenderTree/chromium/DRTTestRunner.h:
(DRTTestRunner):
* DumpRenderTree/chromium/WebViewHost.cpp:
(WebViewHost::requestPointerLock):
(WebViewHost::didAcquirePointerLock):
(WebViewHost::didNotAcquirePointerLock):
* DumpRenderTree/chromium/WebViewHost.h:
(WebViewHost):
(WebViewHost::setPointerLockWillRespondAsynchronously):

LayoutTests:

Add testing for testRunner.setPointerLockWillRespondAsynchronously().

* pointer-lock/pointerlockchange-pointerlockerror-events-expected.txt:
* pointer-lock/pointerlockchange-pointerlockerror-events.html:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127473 268f45cc-cd09-0410-ab3c-d52691b4dbfc
ASSERTion failure when SVG element is removed from document and readded
https://bugs.webkit.org/show_bug.cgi?id=95517
<rdar://problem/12175583>

Reviewed by Brady Eidson.

Previously, SVG animations would cease to animate when their parent
<svg> element was removed and re-added to the document.

Instead, to match Firefox and Opera, we should continue the animation
with the same beginTime (i.e. the animation continues as if it had never
been removed from the document).

Test: svg/animations/reinserting-svg-into-document.html

* svg/SVGSVGElement.cpp:
(WebCore::SVGSVGElement::insertedInto): Don't call begin() on an already-started SMILTimeContainer().
* svg/animation/SMILTimeContainer.cpp:
(WebCore::SMILTimeContainer::isStarted): Added.
* svg/animation/SMILTimeContainer.h: Add isStarted().
* svg/animation/SVGSMILElement.cpp:
(WebCore::SVGSMILElement::insertedInto): Always reschedule SVGSMILElements with
their parent SMILTimeContainer when they are inserted into the document, otherwise
they are lost (and never again update) when their subtree is removed and then
readded to the document.

Add a test that ensures that removing an SVG element from the document
and readding it continues SMIL animations.

* svg/animations/reinserting-svg-into-document.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@127474 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Print API missing documentation when generating gtkdoc
https://bugs.webkit.org/show_bug.cgi?id=95703

Patch by Martin Robinson <mrobinson@igalia.com> on 2012-09-04
Reviewed by Carlos Garcia Campos.

Print out API missing documentation when generating gtkdoc. This makes it
easier to fix documentation errors.

* gtk/generate-gtkdoc:
(print_missing_api): Added.
(generate_doc): Inline the rebase step, since it now reports an error
when you try to rebase without generating documentation first.
* gtk/gtkdoc.py:
(GTKDoc.rebase_installed_docs): Raise an error when rebasing without
generating documentation first to enable a small cleanup at the caller.
(GTKDoc.api_missing_documentation): Added.

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