* frame #0: 0x00000001ce4d2319 WebCore`WebCore::FrameView::sendResizeEventIfNeeded(this=0x00007f9d628f4000) at FrameView.cpp:3398:24 frame #1: 0x00000001ce4d1e91 WebCore`WebCore::FrameView::performPostLayoutTasks(this=0x00007f9d628f4000) at FrameView.cpp:3355:5 frame #2: 0x00000001ce4dc598 WebCore`WebCore::FrameViewLayoutContext::runAsynchronousTasks(this=0x00007f9d628f4138) at FrameViewLayoutContext.cpp:301:12 frame #3: 0x00000001ce4dce7c WebCore`WebCore::FrameViewLayoutContext::runOrScheduleAsynchronousTasks(this=0x00007f9d628f4138) at FrameViewLayoutContext.cpp:287:5 frame #4: 0x00000001ce4bcb50 WebCore`WebCore::FrameViewLayoutContext::layout(this=0x00007f9d628f4138) at FrameViewLayoutContext.cpp:260:9 frame #5: 0x00000001ce4dc4bf WebCore`WebCore::FrameViewLayoutContext::layoutTimerFired(this=0x00007f9d628f4138) at FrameViewLayoutContext.cpp:468:5 The layout zero-delay timer should not trigger "resize" event firing. Resize events should be fired as part of HTML Event Loop.
Actually the poorly-named FrameView::sendResizeEventIfNeeded() calls setNeedsDOMWindowResizeEvent() so maybe it's OK.
(In reply to Simon Fraser (smfr) from comment #1) > Actually the poorly-named FrameView::sendResizeEventIfNeeded() calls > setNeedsDOMWindowResizeEvent() so maybe it's OK. Yeah, we should probably rename that function since that resize event event loop integration patch stuck. I didn't do the rename because it would have made the patch really big and hard to revert.
*** This bug has been marked as a duplicate of bug 220050 ***