Instant Extended: Move omnibox dropdown by 2 pixels

chrome/browser/ui/cocoa/browser_window_controller_private.mm

Index: chrome/browser/ui/cocoa/browser_window_controller_private.mm
diff --git a/chrome/browser/ui/cocoa/browser_window_controller_private.mm b/chrome/browser/ui/cocoa/browser_window_controller_private.mm
index 01821dbde4fab213a873faae0524ee25cd4fe245..a9f0259d25e2c828972b6c39fb575da9d5347edb 100644
--- a/chrome/browser/ui/cocoa/browser_window_controller_private.mm
+++ b/chrome/browser/ui/cocoa/browser_window_controller_private.mm
@@ -261,8 +261,8 @@ willPositionSheet:(NSWindow*)sheet
     // The tabContentArea view starts below the omnibox.
     CGFloat minToolbarHeight = 0;
     if ([self hasToolbar]) {
-      minToolbarHeight = [toolbarController_
-          desiredHeightForCompression:bookmarks::kBookmarkBarOverlap];
+      // -1 to account for the toolbar separator.
+      minToolbarHeight = [toolbarController_ desiredHeightForCompression:0] - 1;

[Nico, 2013/05/16 22:17:57]

Why was this not needed before? This code is independent of any overlays, no?

[sail, 2013/05/16 22:35:30]

Previously the overlay never overlapped the toolbar separator.

If the bookmark bar was pinned then the toolbar didn't draw a separator.
If the bookmark bar was not pinned then the overlay was a few pixels above the
bottom of the toolbar.

Now when the bookmark bar is not pinned it exactly overlaps the toolbar
separator.

[Nico, 2013/05/16 22:55:58]

Should the function just return the right value then? Also, do all callers now
always pass 0 as parameter? If any don't, is that a bug?

chrome/browser/ui/cocoa/bookmarks/bookmark_bar_controller.mm still references
bookmarks::kBookmarkBarOverlap – is that still correct?

[sail, 2013/05/16 23:27:06]

Only the overlay passes a constant value here. That's because the overlay
position is fixed with respect to the omnibox. All other UIs (bookmark bar,
etc...) are relative to the bottom of the toolbar.
Yea, this is still correct.

[Nico, 2013/05/22 22:49:21]

I still don't get it. This code is laying out the normal content area in a
normal browser window, right? How is this line related to the overlay?

[sail, 2013/05/22 23:51:11]

Right.
This lays out the tabContentArea. So in this case the tab content area goes from
0 (bottom) to contentAreaTop (bottom of the toolbar).

Both the overlay and tab contents are subviews of the tab content area.

The overlay is normally displayed at the top of the tabContentArea so its offset
(OverlayableContentsController->overlayContentsOffset_) is usually 0.

The tab contents is normally displayed below any bars at the top of the browser.
So for example, if the bookmark bar was pinned then the offset
(OverlayableContentsController->activeContainerOffset_) would be 26.

[Robert Sesek, 2013/05/24 18:36:23]

Why is this not desiredHeightForCompresssion:1 ?

And shouldn't it be cr_lineWidth?

[sail, 2013/05/24 19:58:02]

Good idea, done.
The view height is an integral value. The actual drawing height is cr_lineWidth.

     }
     contentAreaTop = toolbarTopY - minToolbarHeight;
     // This is the space between the bottom of the omnibox and the bottom of the