Fix compositing chicken and egg problem in updateControlTints.

Source/core/frame/FrameView.cpp

 /*
  * Copyright (C) 1998, 1999 Torben Weis <weis@kde.org>
  *                     1999 Lars Knoll <knoll@kde.org>
  *                     1999 Antti Koivisto <koivisto@kde.org>
  *                     2000 Dirk Mueller <mueller@kde.org>
  * Copyright (C) 2004, 2005, 2006, 2007, 2008 Apple Inc. All rights reserved.
  *           (C) 2006 Graham Dennis (graham.dennis@gmail.com)
  *           (C) 2006 Alexey Proskuryakov (ap@nypop.com)
  * Copyright (C) 2009 Google Inc. All rights reserved.
  *
@@ skipping 2609 matching lines @@
     // We do a "fake" paint, and when the theme gets a paint call, it can then do an invalidate.
     // This is only done if the theme supports control tinting. It's up to the theme and platform
     // to define when controls get the tint and to call this function when that changes.
 
     // Optimize the common case where we bring a window to the front while it's still empty.
     if (m_frame->document()->url().isEmpty())
         return;
 
     // FIXME: Why do we need this for hasCustomScrollbars?
     // FIXME: supportsControlTints is currently true for a bunch of platforms.
-    // It should only be for Mac 10.6.
     if (!RenderTheme::theme().supportsControlTints() && !hasCustomScrollbars())
         return;
 
-    if (needsLayout())
-        layout();
+    // Updating layout can run script, which can tear down the FrameView.
+    RefPtr<FrameView> protector(this);
+    updateLayoutAndStyleForPainting();
+
     // FIXME: The use of paint seems like overkill: crbug.com/236892
     GraphicsContext context(0); // NULL canvas to get a non-painting context.
     context.setUpdatingControlTints(true);
     paint(&context, frameRect());
 }
 
 bool FrameView::wasScrolledByUser() const
 {
     return m_wasScrolledByUser;
 }
@@ skipping 125 matching lines @@
         return;
 
     if (isMainFrame()) {
         if (m_frame->page()->chrome().client().paintCustomOverhangArea(context, horizontalOverhangArea, verticalOverhangArea, dirtyRect))
             return;
     }
 
     ScrollView::paintOverhangAreas(context, horizontalOverhangArea, verticalOverhangArea, dirtyRect);
 }
 
+void FrameView::updateLayoutAndStyleForPainting()
+{
+    // Updating layout can run script, which can tear down the FrameView.
+    RefPtr<FrameView> protector(this);
+
+    updateLayoutAndStyleIfNeededRecursive();
+    if (RenderView* view = renderView())
+        view->compositor()->updateCompositingLayers();
+}
+
 void FrameView::updateLayoutAndStyleIfNeededRecursive()
 {
     // We have to crawl our entire tree looking for any FrameViews that need
     // layout and make sure they are up to date.
     // Mac actually tests for intersection with the dirty region and tries not to
     // update layout for frames that are outside the dirty region.  Not only does this seem
     // pointless (since those frames will have set a zero timer to layout anyway), but
     // it is also incorrect, since if two frames overlap, the first could be excluded from the dirty
     // region but then become included later by the second frame adding rects to the dirty region
     // when it lays out.
@@ skipping 412 matching lines @@
 void FrameView::willRemoveScrollbar(Scrollbar* scrollbar, ScrollbarOrientation orientation)
 {
     ScrollableArea::willRemoveScrollbar(scrollbar, orientation);
     if (AXObjectCache* cache = axObjectCache()) {
         cache->remove(scrollbar);
         cache->handleScrollbarUpdate(this);
     }
 }
 
 } // namespace WebCore