Handle titlebar text updates properly

chrome/browser/ui/views/frame/opaque_browser_frame_view.cc

Index: chrome/browser/ui/views/frame/opaque_browser_frame_view.cc
diff --git a/chrome/browser/ui/views/frame/opaque_browser_frame_view.cc b/chrome/browser/ui/views/frame/opaque_browser_frame_view.cc
index a7b7c34c4555eb778deaca1d35f180c556514ba6..fc9cf560e46ad56a5a057a7ba4f76b9b0993acb1 100644
--- a/chrome/browser/ui/views/frame/opaque_browser_frame_view.cc
+++ b/chrome/browser/ui/views/frame/opaque_browser_frame_view.cc
@@ -377,6 +377,11 @@ void OpaqueBrowserFrameView::UpdateWindowIcon() {
   window_icon_->SchedulePaint();
 }
 
+void OpaqueBrowserFrameView::UpdateWindowTitle() {
+  if (!frame()->IsFullscreen())
+    SchedulePaintInRect(title_bounds_);

[msw, 2012/09/28 20:10:51]

This particular implementation may be unnecessary after http://crrev.com/159087,
but I haven't looked closely at this patch.

Now, a views::Label title schedules a paint internally on text changes, etc.
I'd favor a solution of using more Labels titles in NonClientView, if possible.
Standard views components should simplify these common critical tasks.

[Mr4D (OOO till 08-26), 2012/09/28 20:30:48]

This particular: You may be right. I was adding this since I am not sure how
many broken cases we have. So I might be able to remove this.

for views::Label - well - there are several different things being used,
dependent on which frame you are looking: there is a frame_painter, there are
labels and there are self drawing frames. But instead of adding another Label
object to every frame object it might be easier to simplify the entire frame
handling. (not with this CL for sure - especially because this CL is targetted
towards M23).

[msw, 2012/09/28 20:42:51]

Okay, let me know if you'd like my full review here or help with any followup.

+}
+
 ///////////////////////////////////////////////////////////////////////////////
 // OpaqueBrowserFrameView, views::View overrides: