Actually, this works on Windows now.

Is there a difference for the architecture between Mac and Linux?

 Issue 48240  already tracks this bug for Linux.  Is this a dupe or should this be set of OS:Mac only?

(No comment was entered for this change.)

I'm fairly positive that Linux has the same issue because we share the same WrenchMenuModel (Windows does not, which may be why this behavior doesn't occur there) and it reproduces the same on Linux. It really depends on how GTK menus work, which I'm not familiar with. I have not verified in the debugger if this is is truly the same issue, though.

@sky: Did you do anything special to work around this on Windows?

- I am unsure about the semantics about having things in menus that don't close the menu. I am too used to opening the menu with button down and selecting by releasing. What happens in that case?
- I'm pretty sure windows uses the same wrench menu model as linux.
- This is impossible in linux (with the current implementation), since we're really just cleverly piggybacking on the normal menu activate signal. The current implementation does as little as possible as to maintain as much native semantics as possible.
- There may also be linux issues because of spinning up another message loop. I'm unsure about this point.

Prognosis: hard to do and debatably the wrong thing.

On windows we no longer use the system menus, so we can customize in whatever way we want.

> - I am unsure about the semantics about having things in menus that don't close the
> menu. I am too used to opening the menu with button down and selecting by releasing.
> What happens in that case?

On windows if you click on the wrench, hold the mouse button down, drag over the zoom buttons and release we'll update the zoom and the menu remains open. OTOH if you do the same thing over the cut/copy/paste buttons we'll do the cut/copy/paste then close the menu.

> - There may also be linux issues because of spinning up another message loop. I'm unsure about this point.

views/gtk does this and to date we haven't had many issues.

(No comment was entered for this change.)

This is for Mac, too. Unmerging.

(No comment was entered for this change.)

 Issue 49978  has been merged into this issue.

I claim that press-drag-release should result in the menu closing, while click-move-click should result in it staying open as this requests.  (But only for zoom items.)  Just because it's really weird to have click-drag-release not close the menu.

I could be wrong.

 Issue 50232  has been merged into this issue.

(No comment was entered for this change.)

I’d like to add that the middle part of the zoom button in the wrench menu (the part with the current zoom percentage text) should itself be a button that resets the zoom to 100%.

 Issue 52334  has been merged into this issue.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

Verified label updated by AutoAllocator, contact AmolK or KrisR for details

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=56566 

------------------------------------------------------------------------
r56566 | rsesek@chromium.org | 2010-08-18 11:36:57 -0700 (Wed, 18 Aug 2010) | 11 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/menu_tracked_button.h?r1=56566&r2=56565
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/menu_tracked_button.mm?r1=56566&r2=56565
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/wrench_menu_controller.h?r1=56566&r2=56565
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/wrench_menu_controller.mm?r1=56566&r2=56565
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/resource_message_filter.cc?r1=56566&r2=56565
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui_thread_helpers.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui_thread_helpers_linux.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui_thread_helpers_mac.mm
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui_thread_helpers_win.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/wrench_menu_model.h?r1=56566&r2=56565
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=56566&r2=56565

[Mac] Don't close the Wrench menu after using the zoom buttons if the menu was opened sticky.

This runs the Task that updates the zoom information in the UI thread outside of the
normal MessageLoop and instead runs it on the native run loop.

R=mark
BUG=48679
TEST=Open Wrench menu with a click. Use zoom buttons. Menu stays open and page zooms. Other buttons still close menu.
TEST=Open Wrench menu with click-hold-drag. Hover and release on zoom buttons. Menu closes and page zooms.

Review URL: http://codereview.chromium.org/3183013
------------------------------------------------------------------------

Verified in 7.0.503.0 (Official Build 57033) dev

This doesn't work for me on Google Chrome	7.0.503.1 (Official Build 57041) dev
in Linux.

If I click on Zoom buttons, wrench menu closes.

@mahaniok, that's because this is a OS:Mac only bug that has been fixed.

The Linux version of this bug is  Issue 48240