diff options
author | ben@chromium.org <ben@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-06-18 17:03:12 +0000 |
---|---|---|
committer | ben@chromium.org <ben@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-06-18 17:03:12 +0000 |
commit | 21756fe51178ee6c662f9add3e4c34be9e44c83a (patch) | |
tree | fa08ca0f6596e58f937a6d286bc6c9cbde23e601 /chrome/browser/dock_info_gtk.cc | |
parent | 1ccf116b017f7a6095c8f15caeae2d5f48db2aef (diff) | |
download | chromium_src-21756fe51178ee6c662f9add3e4c34be9e44c83a.zip chromium_src-21756fe51178ee6c662f9add3e4c34be9e44c83a.tar.gz chromium_src-21756fe51178ee6c662f9add3e4c34be9e44c83a.tar.bz2 |
A long standing bug in views!
Every time a widget is resized, we call Layout on its view hierarchy TWICE!
A while ago, I added code to views::View's default implementation of DidChangeBounds to automatically call Layout. So, after calling SetBounds on a widget, it is not necessary to call Layout. However this is exactly what WidgetWin/WidgetGtk do o_O.
It turns out this doesn't matter on windows because size changes in child widgets never affect the sizes of their parents - they're just clipped to their parent's bounds.
However, on Gtk it seems like sizing a child causes a size-allocate signal to be sent to the parent widget, which means we end up in infinite resize loops.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/131026
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18714 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/dock_info_gtk.cc')
0 files changed, 0 insertions, 0 deletions