Reproduction: <!DOCTYPE html> <style> p:first-letter { overflow: -webkit-marquee; float: left; } </style> <p>a</p> Crash reproduces so far in: Safari 5.0.5 (7533.21.1) Win32 Chrome 14.0.822.0 (Developer Build 92402) WebKit 535.1 (trunk@90358) Linux Ubuntu 11.04 (x86_64), Win32 Chrome 13.0.782.56 (Official Build 92025) Beta Linux Ubuntu 11.04 (x86_64) Chrome 12.0.742.122 Stable Win32 crbug.com/89595
Noel, why did you mark this security ? To me, this looks a obvious null ptr exception crash. this and renderer() vtables are all right and renderer()->node() is an anonymous node, so null. I have also hit this in my fuzzers, so remember analyzing this. Am i missing anything ? renderer()->node()->document()->eventQueue()->enqueueOrDispatchScrollEvent(renderer()->node(), EventQueue::ScrollEventElementTarget);
<rdar://problem/9792726>
(In reply to comment #1) > Noel, why did you mark this security ? I was not concerned about Chromium; there it's a tab crash. My concern was for Safari and other WebCore users. Should I consider simple ways to crash those users as a security matter or not?
Null ptr crashes are not security bugs.
ASSERTION FAILED: this /Users/ap/Safari/OpenSource/Source/WebCore/dom/Node.h(365) : WebCore::Document* WebCore::Node::document() const 1 WebCore::Node::document() const 2 WebCore::RenderLayer::scrollTo(int, int) 3 WebCore::RenderLayer::setScrollOffset(WebCore::IntPoint const&) 4 WebCore::ScrollableArea::setScrollOffsetFromAnimation(WebCore::IntPoint const&) 5 WebCore::ScrollAnimator::notityPositionChanged() 6 WebCore::ScrollAnimatorMac::notityPositionChanged() 7 WebCore::ScrollAnimatorMac::immediateScrollToPoint(WebCore::FloatPoint const&) 8 WebCore::ScrollAnimatorMac::scrollToOffsetWithoutAnimation(WebCore::FloatPoint const&) 9 WebCore::ScrollableArea::scrollToOffsetWithoutAnimation(WebCore::FloatPoint const&) 10 WebCore::RenderLayer::scrollToOffset(int, int, WebCore::RenderLayer::ScrollOffsetClamping) 11 WebCore::RenderMarquee::start() ...
Created attachment 102281 [details] Patch
Comment on attachment 102281 [details] Patch How about to use renderer()->document() ?
(In reply to comment #7) > (From update of attachment 102281 [details]) > How about to use renderer()->document() ? That would allow us to dispatch a scroll event but as there is no corresponding dom node to set the target to I'm not sure how useful that event would be.
Comment on attachment 102281 [details] Patch Clearing flags on attachment: 102281 Committed r92025: <http://trac.webkit.org/changeset/92025>
All reviewed patches have been landed. Closing bug.