diff options
| author | avi@chromium.org <avi@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-08-12 20:39:41 +0000 |
|---|---|---|
| committer | avi@chromium.org <avi@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-08-12 20:39:41 +0000 |
| commit | 44838a83ab6f2dec072a044316142ffd819f3e49 (patch) | |
| tree | 428c4e5bf1cfc0a0870d369dedbcb797691f8d7f /chrome/browser/cocoa/delayedmenu_button.mm | |
| parent | 885b72726cd788273b305da33d04c65cfa130d09 (diff) | |
| download | chromium_src-44838a83ab6f2dec072a044316142ffd819f3e49.zip chromium_src-44838a83ab6f2dec072a044316142ffd819f3e49.tar.gz chromium_src-44838a83ab6f2dec072a044316142ffd819f3e49.tar.bz2 | |
(Mac) Place back/forward toolbar menu correctly when there's a bookmark
bar.
It turns out that the frame is in the DelayedMenuButton's coordinate
system, but a fudge is needed to make things line up. (I don't
understand these fudges, especially vertically.)
Patch by viettrungluu.
BUG=http://crbug.com/19174
TEST=Surf a bit, check back menu with and without bookmark bar.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23216 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/cocoa/delayedmenu_button.mm')
| -rw-r--r-- | chrome/browser/cocoa/delayedmenu_button.mm | 20 |
1 files changed, 9 insertions, 11 deletions
diff --git a/chrome/browser/cocoa/delayedmenu_button.mm b/chrome/browser/cocoa/delayedmenu_button.mm index 9eabf67..5269730 100644 --- a/chrome/browser/cocoa/delayedmenu_button.mm +++ b/chrome/browser/cocoa/delayedmenu_button.mm @@ -96,17 +96,15 @@ return; } - // FIXME(viettrungluu@gmail.com): Don't ask me. I don't know what's going on. - // But it yields unquestionably right results (even when the menu has to flip - // upwards because you've stupidly dragged the top of the window to the bottom - // of the screen) -- this demonstrates that the y-coordinate (in our - // superview's coordinates) is right. The x-coordinate (in our coordinates) is - // right since the menu appears horizontally in the right place (more or - // less). The |- 2.0| factor is an inexplicable fudge to make it approximately - // line up. If someone figures out what's going on, please fix this. - NSRect frame = [self frame]; - frame.origin.x = [self convertPoint:frame.origin - fromView:[self superview]].x - 2.0; + // FIXME(viettrungluu@gmail.com): We have some fudge factors below to make + // things line up (approximately). I wish I knew how to get rid of them. (Note + // that our view is flipped, and that frame should be in our coordinates.) + // The y/height is very odd, since it doesn't seem to respond to changes the + // way that it should. I don't understand it. + NSRect frame = [self convertRect:[self frame] + fromView:[self superview]]; + frame.origin.x -= 2.0; + frame.size.height += 10.0; // Make our pop-up button cell and set things up. This is, as of 10.5, the // official Apple-recommended hack. Later, perhaps |-[NSMenu |