Crash under RenderLayer::scrollTo() with marquee
authorsimon.fraser@apple.com <simon.fraser@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sun, 7 Jan 2018 05:48:47 +0000 (05:48 +0000)
committersimon.fraser@apple.com <simon.fraser@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sun, 7 Jan 2018 05:48:47 +0000 (05:48 +0000)
commit1af3fc0dabc26bec0f1f32de071b2b748e917294
tree54e84bf7b2b76eea6b4ab4b4b0b97a1478361be1
parentbe723331df53b354aa04fdc8c4dd695813e6a3e6
Crash under RenderLayer::scrollTo() with marquee
https://bugs.webkit.org/show_bug.cgi?id=181349
rdar://problem/36190168

Reviewed by Zalan Bujtas.

Source/WebCore:

Don't call updateWidgetPositions() synchonously during RenderLayer scrolling, because it
can run arbitrary script which may trigger destruction of this RenderLayer.

Instead, queue up updateWidgetPositions() on a zero-delay timer.

Under some circumstances this may allow a paint to occur before the widgets have been
updated (which could be fixed with a more invasive change), but in practice I saw no
painting issues with plug-ins or iframes inside overflow scroll, in WebKit or LegacyWebKit.

Test: fast/scrolling/marquee-scroll-crash.html

* page/FrameView.cpp:
(WebCore::FrameView::FrameView):
(WebCore::FrameView::updateWidgetPositions):
(WebCore::FrameView::scheduleUpdateWidgetPositions):
(WebCore::FrameView::updateWidgetPositionsTimerFired):
* page/FrameView.h:
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::scrollTo):

LayoutTests:

* fast/scrolling/marquee-scroll-crash-expected.txt: Added.
* fast/scrolling/marquee-scroll-crash.html: Added.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@226491 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests/ChangeLog
LayoutTests/fast/scrolling/marquee-scroll-crash-expected.txt [new file with mode: 0644]
LayoutTests/fast/scrolling/marquee-scroll-crash.html [new file with mode: 0644]
Source/WebCore/ChangeLog
Source/WebCore/page/FrameView.cpp
Source/WebCore/page/FrameView.h
Source/WebCore/rendering/RenderLayer.cpp