When it is turned on, leading component is resized when split view gets new bounds.
Review URL: http://codereview.chromium.org/155214
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20258 0039d316-1c4b-4281-b951-d872f2087c98
Fixed the offset-by-taskbar logic.
Tested with dual monitors, trying left-right and up-down monitor layouts.
TEST=Use dual monitors (first:left, second:right) and open, close, and reopen Chromium in the second (right) window. Without this change, the window appears far to the right from the last location.
BUG=15199
Review URL: http://codereview.chromium.org/155201
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20246 0039d316-1c4b-4281-b951-d872f2087c98
I mvoed the implementation of the previously-inline amimate function to the .cc file so we don't have to depend on STL includes in the header.
Review URL: http://codereview.chromium.org/155170
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20091 0039d316-1c4b-4281-b951-d872f2087c98
this we might not end up with the correct size.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/149111
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19657 0039d316-1c4b-4281-b951-d872f2087c98
It was previously landed and reverted because it broke the reliability tests.
http://codereview.chromium.org/125148
The breakage was caused by constrained windows not getting a hold of the FocusManager when in unparented tabs.
The fix is to ensure unparented tab still have a way to access their FocusManager for proper closure.
Files changed from the previous patch that need reviewing:
native_tab_contents_container_win.cc
tab_contents_view_win.h
tab_contents_view_win.cc
BUG=None
TEST=Run all tests (unit, ui, interactive). Extensively test the focus in Chrome.
Review URL: http://codereview.chromium.org/146093
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19617 0039d316-1c4b-4281-b951-d872f2087c98
I believe this may fix a crash where the code indexes out of bounds in the vector. The trouble is the assumption that the native menu index matches the index into the vector. If someone has installed a windows addon this may not be true. It's safer to restrict the iteration to the bounds of the vector and index into the menu based on that.
http://crbug.com/14600
TEST=none
Review URL: http://codereview.chromium.org/150061
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19558 0039d316-1c4b-4281-b951-d872f2087c98
The menu's host window, the message window that receives notifications from the native menu about selection changes, is destroyed, however if the menu is still active it will continue to send messages to it. SDK docs say properties set with SetProp should be removed with RemoveProp before a window is finally NCDESTROYed. The code wasn't doing this, so it was still theoretically possible for the code in the message window's window procedure to locate "something" on that property.
http://crbug.com/14594
TEST=none
Review URL: http://codereview.chromium.org/147230
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19411 0039d316-1c4b-4281-b951-d872f2087c98
SchedulePaint is invoked consecutively with different regions. Windows
has similar code.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/147170
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19338 0039d316-1c4b-4281-b951-d872f2087c98
saving/retrieving/adjusting window positions.
TEST=Open Chrome windows and see if they are placed properly.
TESTED=gcl try, manually
BUG=none
Review URL: http://codereview.chromium.org/141039
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19012 0039d316-1c4b-4281-b951-d872f2087c98
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
wired up yet, but will be shortly.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/126235
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18653 0039d316-1c4b-4281-b951-d872f2087c98
There was a bug in NativeViewHostGtk - reparenting needs to be done atomically using gtk_widget_reparent since GtkWidgets are refcounted and when removed from a container are released, causing a crash when a TabContents is reparented.
The code now compiles thanks to a stubbed BlockedPopupContainer, however there is one remaining issue - the browser window no longer paints and the app instantly hangs. However this is better than the current state so I figured I'd send the code review.
Review URL: http://codereview.chromium.org/126107
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18588 0039d316-1c4b-4281-b951-d872f2087c98
Remove stub implementation in temp_scaffolding_stubs.h
Use l10n_util collator helper function in TableModel::Compare
Review URL: http://codereview.chromium.org/126184
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18518 0039d316-1c4b-4281-b951-d872f2087c98
This requires bringing the owner-draw system for native menus over from the old code. I haven't really changed anything in it other than the format of dwItemData. This code could be improved/simplified by using gfx::Canvas more, but don't want to do it here.
BUG=none
TEST=make sure BackForwardMenuModel tests still pass, test the menu functionality in the toolbar.
Review URL: http://codereview.chromium.org/126092
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18454 0039d316-1c4b-4281-b951-d872f2087c98
This change makes traversal order of focus cycle consistent between forward and backward traversal. This is a partial fix for issue 6785.
BUG=http://crbug.com/6785
TEST=Move the focus to the find bar, and push [Shift]+[Tab]. The focus should not cycle inside the find bar, but go out to the omnibox (or somewhere outside the find bar).
Review URL: http://codereview.chromium.org/125130
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18402 0039d316-1c4b-4281-b951-d872f2087c98
Previously we had three classes of PlatformCanvas*, one for each platform. Then
we had a typedef of PlatformContext to PlatformCanvas[Mac|Win|Linux] for the
specific platform.
This means that it was almost impossible to forward-declare PlatformCanvas and
there were a bunch of unnecessary includes of platform_canvas.h in header
files.
This change makes there be only one platform_canvas.h header with ifdefs, which
removes a decent amount of duplicated code. There is a platform-independent
file, and one platform-dependent file of platform_canvas for each platform.
I also renamed PlatformDevice[Mac|Win|Linux] to PlatformDevice, althouth in
this case I kept the separate headers since there was much less overlap.
I also broke out CanvasPaint into separate headers so this template doesn't
need to be included all over the project (only a couple of files actually need
it).
Review URL: http://codereview.chromium.org/125109
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18363 0039d316-1c4b-4281-b951-d872f2087c98
This change fixes several problems in handling focus traversal and resolves TabbedPane's traversal order issue.
Reversed focus traversal is very tricky, and the original traversal code overlooked several things.
(1) A focusable view may have a FocusTraverasble.
(2) When we are going down, we have to check if the current view has a FocusTraversable.
(3) When we are going up from a FocusTraversable, the parent view may gain the next focus.
This change fixes these issues.
BUG=6871
TEST=See issue 6871.
Review URL: http://codereview.chromium.org/125062
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18335 0039d316-1c4b-4281-b951-d872f2087c98
pfeldman@chromium.org