Function names on Object.prototype should be common identifiers
https://bugs.webkit.org/show_bug.cgi?id=117614

Reviewed by Darin Adler.

Source/JavaScriptCore: 

Patch written by Sam Weinig. Make Object's prototype function names common identififers since they're used frequently.

* runtime/CommonIdentifiers.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::reset):
* runtime/JSObject.h:
* runtime/ObjectPrototype.cpp:
(JSC::ObjectPrototype::finishCreation):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):

Source/WebCore: 

Use the added common identifiers.

* bindings/js/JSDOMWindowBase.cpp:
(WebCore::JSDOMWindowBase::finishCreation):
(WebCore::JSDOMWindowBase::updateDocument):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151605 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r150651): Web Audio doesn't work at all (silence or squawks) on Mountain Lion
https://bugs.webkit.org/show_bug.cgi?id=117652

Reviewed by Eric Carlson.

r150651 disabled setting the buffer size to a large value, but in so doing, also
disabled setting the buffer size to a small value for Web Audio. Narrow the Mountain
Lion protection to just the <video> element case.

* platform/audio/mac/AudioSessionManagerMac.cpp:
(AudioSessionManager::updateSessionState):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151606 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WKPageFindStringMatches ignores the kWKFindOptionsBackwards option.
https://bugs.webkit.org/show_bug.cgi?id=117647
<rdar://problem/13881024>

Source/WebCore: 

Reviewed by Darin Adler.
        
The API returns the matched ranges in the DOM order regardless of the
find direction, but the index of the first match after the user selection
should take the find direction into account.

Extended existing test in TestWebKitAPI.

* page/Page.cpp:
(WebCore::Page::findStringMatchingRanges): Added handling of the Backwards case.
* page/Page.h: Fixed incorrect name of the enum.

Source/WebKit2: 

Reviewed by Darin Adler.
        
The API returns the matched ranges in the DOM order regardless of the
find direction, but the index of the first match after the user selection
should take the find direction into account.

Extended existing test in TestWebKitAPI.

* Shared/API/c/WKFindOptions.h: Added enum for the case where there are
no matches after the user selection in the direction of the find.

Tools: 

Reviewed by Darin Adler.
        
The test now uses content with a selection and tests both
forwards and backward find as well as the case of a find
that has no matches after the user selection.

* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WebKit2/FindMatches.mm:
(TestWebKitAPI::didFindStringMatches):
* TestWebKitAPI/Tests/WebKit2/findRanges.html: Added.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151607 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add support for AVFoundation-backed HTMLMediaElements in the WebVideoFullScreenController.
https://bugs.webkit.org/show_bug.cgi?id=117597

Reviewed by Eric Carlson.

Source/WebCore:

Check for media elements with AVFoundation media types and create a AVPlayerLayer
rather than a QTMovieLayer.

* platform/mac/WebVideoFullscreenController.h:
* platform/mac/WebVideoFullscreenController.mm:
(-[WebVideoFullscreenController setupVideoOverlay:]): Take a CALayer rather than a
    QTMovieLayer. Move the code which connects the layer with it's media source into
    setMediaElement.
(-[WebVideoFullscreenController windowDidLoad]): Give the window's contentView a generic
    CALayer instaead of a QTMovieLayer.
(-[WebVideoFullscreenController setMediaElement:]): Test whether the incoming media
    element is backed by a QTMovie or an AVPlayer, and create the appropriate layer.
(-[WebVideoFullscreenController windowDidExitFullscreen]): Remove the observer of
    AVPlayer's rate property.
(-[WebVideoFullscreenController observeValueForKeyPath:ofObject:change:context:]):
    If the keyPath is "rate", call rateChanged.

Source/WebKit/mac:

Allow AVFoundation to be enabled even when the FullScreen API is disabled.

* WebView/WebView.mm:
(-[WebView _preferencesChanged:]):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151608 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Report the memory cost of HTMLMediaElements to GC.
https://bugs.webkit.org/show_bug.cgi?id=117608

Reviewed by Darin Adler.

Report the extra memory cost of a HTMLMediaElement to the VM, in order to
encourage GC to occur after a media element is removed from the DOM.

Because we cannot know for sure the memory cost of our underlying media
framework objects, use the worst case scenario for the media memory cost:
the buffered percentage of movie * the total data length of the movie.

* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::HTMLMediaElement): Initialize m_reportedExtraMemoryCost.
(WebCore::HTMLMediaElement::removedFrom): Report the extra memory cost.
* html/HTMLMediaElement.h:
* html/TimeRanges.cpp:
(TimeRanges::totalDuration): Added convenience function.
* html/TimeRanges.h:
* platform/graphics/MediaPlayer.cpp:
(WebCore::MediaPlayer::extraMemoryCost): Pass to MediaPlayerPrivate.
* platform/graphics/MediaPlayer.h:
* platform/graphics/MediaPlayerPrivate.h:
(WebCore::MediaPlayerPrivateInterface::extraMemoryCost): Default to 0.
* platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:
(WebCore::MediaPlayerPrivateAVFoundation::extraMemoryCost): Return the percentage
    loaded * total data length.
* platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151609 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Introduce USE(WINGDI) for the Windows port
https://bugs.webkit.org/show_bug.cgi?id=116138

Reviewed by Ryosuke Niwa.

Using USE(WINGDI) instead of OS(WINCE) will allow us to
compile the GDI based Windows port on WinNT too.

.:

* Source/cmake/OptionsWinCE.cmake:

Source/WebCore:

* config.h:
* platform/graphics/BitmapImage.h:
* platform/graphics/FontPlatformData.h:
* platform/graphics/GlyphBuffer.h:
(WebCore):
(GlyphBuffer):
* platform/graphics/Gradient.h:
(Gradient):
* platform/graphics/GraphicsContext.cpp:
(WebCore):
* platform/graphics/GraphicsContext.h:
(WebCore):
(GraphicsContext):
* platform/graphics/ImageBufferData.h:
* platform/graphics/NativeImagePtr.h:
(WebCore):
* platform/graphics/Path.h:
* platform/graphics/Pattern.h:
* plugins/win/PluginViewWin.cpp:
(WebCore::PluginView::paintWindowedPluginIntoContext):
(WebCore::PluginView::paint):
(WebCore::PluginView::snapshot):

Source/WTF:

* wtf/Platform.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151610 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Threaded HTML parser can ASSERT in some situations
https://bugs.webkit.org/show_bug.cgi?id=117662

Reviewed by Ryosuke Niwa.

Source/WebCore:

This patch merges https://chromium.googlesource.com/chromium/blink/+/3c0a112b42d72c7623f78463166dd7f04d680b4c

--->8---
The parser is supposed to stop processing data when there's a pending
location change, but before this CL we would actually process the first
token from every chunk when there was a pending location change.

If the first token in a chunk was a "script" start tag, that would put
the tree builder into TextMode, which can only process character
tokens. If the next chunk starts with another start tag token, the tree
builder would be sad and hit an ASSERT.

This CL reorders a couple lines in HTMLDocumentParser so that we check
for pending location changes before processing any tokens. This change
stops us from processing the first token from each chunk while there is
a pending location change.

This issue can reproduce on any platform, but it reproduced often on
Android because mobile markup often elides spaces between consecutive
script tags. If there are space characters between the script tags,
then those space characters will be the first ones processes in the
chunk, which doesn't trigger the ASSERT.
---8<---

Since we landed this patch in Blink, we've been able to reproduce this
issue on desktops as well. I spoke with rniwa in #webkit and he said
that WebKit doesn't have any current plans to enable the threaded
parser but that it was probably worth merging this patch anyway.

Test: http/tests/navigation/pending-location-change-assert.html

* html/parser/HTMLDocumentParser.cpp:
(WebCore::HTMLDocumentParser::processParsedChunkFromBackgroundParser):

LayoutTests:

* http/tests/navigation/pending-location-change-assert-expected.txt: Added.
* http/tests/navigation/pending-location-change-assert.html: Added.
* http/tests/resources/slow-notify-done.php: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151611 268f45cc-cd09-0410-ab3c-d52691b4dbfc
background-color is not preserved when inserting a new paragraph
https://bugs.webkit.org/show_bug.cgi?id=117138

Patch by Lukasz Gajowy <l.gajowy@samsung.com> on 2013-06-14
Reviewed by Ryosuke Niwa.

Source/WebCore:

The style isn't copied because background-color isn't defined as inheritable property.

Test: editing/inserting/insert-paragraph-not-preserving-background-color.html

* editing/InsertParagraphSeparatorCommand.cpp:
(WebCore::InsertParagraphSeparatorCommand::calculateStyleBeforeInsertion):
Passing EditingPropertiesInEffect instead of implicit parameter OnlyEditingInheritableProperties.

LayoutTests:

Adding layout test and expected result to reproduce the issue.

* editing/inserting/insert-paragraph-with-font-and-background-color-expected.txt: Added.
* editing/inserting/insert-paragraph-with-font-and-background-color.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151612 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r148367): Facebook and Twitter icons at macworld.com are stacked vertically, obscuring Twitter one
https://bugs.webkit.org/show_bug.cgi?id=117284

Reviewed by David Hyatt.

Source/WebCore:

Test: fast/text/whitespace/inline-whitespace-wrapping-7.html

We were looking for line breaks in trailing collapsed whitespace even when inside a nowrap inline.
It's wrong to do this as we don't know yet if we will want or need to break - that decision has to
be deferred until we enter a part of the line that is autowrap.

* rendering/RenderBlockLineLayout.cpp:
(WebCore::RenderBlock::LineBreaker::nextSegmentBreak):

LayoutTests:

* fast/text/whitespace/inline-whitespace-wrapping-7-expected.html: Added.
* fast/text/whitespace/inline-whitespace-wrapping-7.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151613 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Reorder my email addresses.
https://bugs.webkit.org/show_bug.cgi?id=100122

Patch by Bruno de Oliveira Abinader <brunoabinader@gmail.com> on 2013-06-15

* Scripts/webkitpy/common/config/contributors.json:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151614 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Crash in supportsSnapshotting
https://bugs.webkit.org/show_bug.cgi?id=117670
<rdar://problem/14059711>

Reviewed by Darin Adler.

Speculative fix for deferencing a null RefPtr in supportsSnapshotting.
It seems like it was possible to get in a state where the plugin machinery
would fire up and attempt to get a screenshot before there was an active
connection to the plugin process (usually under periods of high load, such
as opening a lot of tabs at once). In this case we're now returning false
from supportsSnapshotting, which will trigger the plugin to restart, but
that's better than requesting a snapshot on something that doesn't yet exist.

* WebProcess/Plugins/PluginProxy.cpp:
(WebKit::PluginProxy::supportsSnapshotting): Guard for an empty connection object.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151617 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Support using clang instead of gcc for bindings preprocessing
https://bugs.webkit.org/show_bug.cgi?id=117674

Reviewed by Sam Weinig.

I couldn't build on my computer because I don't have gcc installed.
This is my cut at fixing it.

* bindings/scripts/CodeGeneratorObjC.pm:
(ReadPublicInterfaces): Use clang if present.
* bindings/scripts/preprocessor.pm:
(applyPreprocessor): Ditto.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151619 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Move Pasteboard::getStringSelection to Editor, fixing a layering violation
https://bugs.webkit.org/show_bug.cgi?id=117673

Reviewed by Ryosuke Niwa.

* editing/Editor.h: Added stringSelectionForPasteboardWithImageAltText.

* editing/mac/EditorMac.mm:
(WebCore::Editor::stringSelectionForPasteboard): Moved code here from the Pasteboard
class, since all the Pasteboard class did really was turn around and call back here.
(WebCore::Editor::stringSelectionForPasteboardWithImageAltText): Added. Variant of
the function above that includes image alt text. Separate named functions are often
the best pattern for something like this unless there are many different combinations.

* platform/Pasteboard.h: Remove the Mac-only Pasteboard::getStringSelectioon.

* platform/ios/PasteboardIOS.mm:
(WebCore::Pasteboard::writeSelection):
* platform/mac/PasteboardMac.mm:
(WebCore::Pasteboard::writeSelectionForTypes):
Call the two new functions instead of the old Pasteboard::getStringSelection.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151620 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Try to fix iOS after last Pasteboard change.

        * platform/ios/PasteboardIOS.mm:
        (WebCore::Pasteboard::writeSelection): Put the new code inline here because the
        stringSelectionForPasteboard function is currently Mac-only.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151621 268f45cc-cd09-0410-ab3c-d52691b4dbfc
webkit-backface-visibility on a parent element stops background-position from updating
https://bugs.webkit.org/show_bug.cgi?id=116319

Source/WebCore:

Reviewed by Darin Adler.

The optimization added in r102952 was incorrect in the case where a style change
resulted in a positioned-movement-only layout but also required a repaint; it assumed
that a composited layer did not need to be repainted for a a positioned-movement-only layout.

Fix by making RenderObject::setNeedsLayoutForPositionedMovement() check whether the
style change requires a repaint, and calling setLayerNeedsFullRepaint() in that situation.

Test: compositing/repaint/positioned-movement.html

* rendering/RenderLayer.h: RepaintStatus values do not need to be bit flags.
* rendering/RenderObject.cpp:
(WebCore::RenderObject::setStyle): Pass the old style to setNeedsPositionedMovementLayout().
(WebCore::RenderObject::styleDidChange): Ditto.
* rendering/RenderObject.h:
(WebCore::RenderObject::setNeedsPositionedMovementLayout): Now takes a const RenderStyle*.
* rendering/style/RenderStyle.cpp:
(WebCore::RenderStyle::diff): Remove a comment now that this bug is fixed.
(WebCore::RenderStyle::diffRequiresRepaint): Public wrapper for changeRequiresRepaint().
That function never uses contextSensitiveProperties so we can safely ignore them.
* rendering/style/RenderStyle.h: Expose a way to call changeRequiresRepaint().

LayoutTests:

Reviewed by Darin Adler.

Test that does a positioned-movement-only layout and dumps a layer tree with
repaint rects.

* compositing/repaint/positioned-movement-expected.txt: Added.
* compositing/repaint/positioned-movement.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151622 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore: Painting of fixed background images is wrong in composited layers
https://bugs.webkit.org/show_bug.cgi?id=65793

Reviewed by Sam Weinig.

The code that computed background image geometry for background-attachment:fixed
images was unaware of compositing, so often painting the image at the wrong location.

Fix by having RenderBoxModelObject::calculateBackgroundImageGeometry() do the correct
math for fixed backgrounds in composited layer by offsetting the viewport rect by
the paint container's absolute position.

Tests: compositing/backgrounds/fixed-background-on-descendant.html
       compositing/backgrounds/fixed-backgrounds.html

* rendering/RenderBox.cpp:
(WebCore::RenderBox::getBackgroundPaintedExtent): Now returns a bool indicating
whether it is returning a reliable extent rect. It can return false in the case where
a background is fixed, since computing the correct extent would require finding
the appropriate composited ancestor to pass to calculateBackgroundImageGeometry().
This is OK since this function is used for "background opaque" optimizations.
(WebCore::RenderBox::computeBackgroundIsKnownToBeObscured): If getBackgroundPaintedExtent()
returns false, return false.
(WebCore::RenderBox::maskClipRect): We removed mask-attachment, so we never need to
compute the composited ancestor here and can pass null.
(WebCore::RenderBox::repaintLayerRectsForImage): Unwrap a comment.
If the changed image is related to a fixed background, geometry.hasNonLocalGeometry()
will be true. In that cause, just repaint the entire renderer rather than groveling
around for a composited ancestor.
* rendering/RenderBox.h: Changed name and signature of backgroundPaintedExtent.
* rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::paintFillLayerExtended): calculateBackgroundImageGeometry()
now needs to know the painting container.
(WebCore::RenderBoxModelObject::calculateBackgroundImageGeometry): Now takes a painting
container, that is required to correctly compute the viewport-relative offset for fixed
backgrounds. geometry.setHasNonLocalGeometry() is set for fixed backgrounds to indicate
to callers that, if they didn't pass a paint container, the destRect is not accurate.
The main bug fix is also here: we move the viewportRect by the absolute location of
paint container, which is equivalent to the composited layer offset.
(WebCore::RenderBoxModelObject::getGeometryForBackgroundImage): calculateBackgroundImageGeometry()
takes a paint container.
* rendering/RenderBoxModelObject.h:
(WebCore::RenderBoxModelObject::BackgroundImageGeometry::BackgroundImageGeometry):
(WebCore::RenderBoxModelObject::BackgroundImageGeometry::setHasNonLocalGeometry):
(WebCore::RenderBoxModelObject::BackgroundImageGeometry::hasNonLocalGeometry):
* rendering/RenderImage.cpp:
(WebCore::RenderImage::computeBackgroundIsKnownToBeObscured): If getBackgroundPaintedExtent()
can't cheaply give an accurate answer, return false.
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateDirectlyCompositedBackgroundImage): Pass the paint container,
which is our own renderer.

LayoutTests: Fixed background images behave strangely with webkit transitions
https://bugs.webkit.org/show_bug.cgi?id=65793

Reviewed by Sam Weinig.

Ref tests that compare fixed background rendering after a scroll, with and
without compositing, with a couple of layer configurations.

* compositing/backgrounds/fixed-background-on-descendant-expected.html: Added.
* compositing/backgrounds/fixed-background-on-descendant.html: Added.
* compositing/backgrounds/fixed-backgrounds-expected.html: Added.
* compositing/backgrounds/fixed-backgrounds.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151623 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fixed backgrounds in composited layers not repainted on scrolling
https://bugs.webkit.org/show_bug.cgi?id=117684

Source/WebCore:

Reviewed by Tim Horton.

FrameView is aware that "slow-repaint objects" (i.e. renderers with
background-attachment:fixed) require a slow-scrolling path. However,
it was ignorant of the fact that such objects could be painting into
compositing layers; it simply dirtied the main tiles, and nothing else.

Fix by having FrameView track the slow-repaints objects explicitly, as we
do for position:fixed, and repaint each of them on scrolling.

Test: compositing/repaint/fixed-background-scroll.html

* page/FrameView.cpp:
(WebCore::FrameView::FrameView): No need to initialize m_slowRepaintObjectCount,
which is now an OwnPtr<RenderObjectSet>.
(WebCore::FrameView::useSlowRepaints): Use hasSlowRepaintObjects() now.
(WebCore::FrameView::addSlowRepaintObject): Now adds the object to a set,
allocating the set if necessary.
(WebCore::FrameView::removeSlowRepaintObject): Remove the object from the set,
and deallocate the set if empty.
(WebCore::FrameView::scrollContentsSlowPath): Call repaintSlowRepaintObjects();
this is the change that fixes the bug for always-composited implementations (e.g.
tile cache). This is a conservative change; we still invalidate the tile cache
as well. This could be optimized later.
(WebCore::FrameView::repaintSlowRepaintObjects): Repaint each object in the set.
Their appropriate compositing ancestor will be repainted.
(WebCore::FrameView::scrollPositionChangedViaPlatformWidget): Call
repaintSlowRepaintObjects() so that fixed backgrounds in composited layers are
correctly repainted; this fixes the bug for WebKit1.
* page/FrameView.h: Replace m_slowRepaintObjectCount with a HashSet of
RenderObjects.
(WebCore::FrameView::hasSlowRepaintObject): Takes a RenderObject* now.
(WebCore::FrameView::hasSlowRepaintObjects): Ditto.
* rendering/RenderObject.cpp:
(WebCore::RenderObject::styleWillChange): Pass the RenderObject.
(WebCore::RenderObject::willBeDestroyed): Assert that this RenderObject
has been removed from FrameView's set of slow-repaint objects already, if
the document is not being destroyed.
(WebCore::RenderObject::willBeRemovedFromTree): Pass the RenderObject.

LayoutTests:

Reviewed by Tim Horton.

Test that verifies that a composited layer with a fixed background is repainted
on scrolling.

* compositing/repaint/fixed-background-scroll-expected.txt: Added.
* compositing/repaint/fixed-background-scroll.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151624 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Added new baselines for some of editing/selection tests as r151533 on EFL port.

* platform/efl/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151625 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Added new baselines for some of editing/style tests, which works on EFL port.

* platform/efl/TestExpectations:
* platform/efl/editing/style/5017613-1-expected.png: Added.
* platform/efl/editing/style/5017613-1-expected.txt: Added.
* platform/efl/editing/style/5046875-1-expected.png: Added.
* platform/efl/editing/style/5046875-1-expected.txt: Added.
* platform/efl/editing/style/5065910-expected.png: Added.
* platform/efl/editing/style/5065910-expected.txt: Added.
* platform/efl/editing/style/5228141-expected.png: Added.
* platform/efl/editing/style/5228141-expected.txt: Added.
* platform/efl/editing/style/5279521-expected.png: Added.
* platform/efl/editing/style/5279521-expected.txt: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151626 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix two assertion failures in Range::insertNode
https://bugs.webkit.org/show_bug.cgi?id=116511

Reviewed by Ryosuke Niwa.

Source/WebCore:

> ASSERTION FAILED: childBefore == (offset ? container->childNode(offset - 1) : 0)
> third_party/WebKit/Source/WebCore/dom/RangeBoundaryPoint.h(115) : void WebCore::RangeBoundaryPoint::set(PassRefPtr<WebCore::Node>, int, WebCore::Node *)

> ASSERTION FAILED: child->parentNode()
> ../../third_party/WebKit/Source/core/dom/RangeBoundaryPoint.h(133) : void WebCore::RangeBoundaryPoint::setToBeforeChild(WebCore::Node *)
>  1   0x87594b2 WebCore::RangeBoundaryPoint::setToBeforeChild(WebCore::Node*)
>  2   0x87534a9 WebCore::Range::insertNode(WTF::PassRefPtr<WebCore::Node>, int&)

Range::insertNode calls Node::insertBefore, in which an event handler
can update the DOM structure so that RangeBoundaryPoint don't like. We
postpone event dispatching by EventQueueScope.

Also, remove old comments about Acid3. The behavior is standardized.
(Step 9 of http://dom.spec.whatwg.org/#dom-range-insertnode)

This patch imports http://src.chromium.org/viewvc/blink?view=revision&revision=150470 .

Test: fast/dom/Range/range-insertNode-assertion.html

* dom/Range.cpp:
(WebCore::Range::insertNode):
 - Add EventQueueScope
 - Remove obsolete comments

LayoutTests:

We need to update fast/dom/insertBefore-refChild-crash.html because the
test caused recursive calls to the event handler. container.innerHTML=''
did nothing before this CL. Now container has the newChild because
DOMNodeRemoved event dispatching is delayed until Range::insertNode
completion.

We need to update fast/text/split-text-crash.xhtml so that it doesn't
stop when the event handler is called twice. I'm not sure why the test
worked before this CL.

* fast/dom/Range/range-insertNode-assertion-expected.txt: Added.
* fast/dom/Range/range-insertNode-assertion.html: Added.
* fast/dom/insertBefore-refChild-crash.html:
* fast/text/split-text-crash.xhtml:


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