New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 48679 link

Starred by 16 users

Issue metadata

Status: Verified
Owner:
Closed: Aug 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug
M-7

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Wrench menu should stay open after clicking the zoom buttons

Project Member Reported by rsesek@chromium.org, Jul 9 2010

Issue description

The new wrench menu has the integrated zoom buttons. It'd be great if after clicking these the percentage display would update and the menu stay open. Currently this is impossible because of our architecture:

When the menu is open, it is spinning an event tracking run loop (on Mac at least). This blocks the main message loop of the UI thread. When one of the zoom buttons is pressed, the command is sent down to the renderer. The ResourceMessageFilter then picks up the ack from the renderer and posts a runnable method back to the UI thread to update the HostZoomMap. But because the event tracking loop is still spinning from the menu, the message does not get delivered until after the menu closes and the control returns back to the main message loop.

I don't think this is solvable for M6, but it'd be a nice thing to have.
 

Comment 1 by sky@chromium.org, Jul 9 2010

Labels: -OS-All OS-Linux OS-Mac
Actually, this works on Windows now.

Comment 2 by dhw@chromium.org, Jul 9 2010

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?
Labels: Mstone-7 HelpWanted
Status: Available
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?

Comment 5 by e...@chromium.org, Jul 9 2010

- 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.

Comment 6 by sky@chromium.org, Jul 9 2010

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.

Comment 7 by evan@chromium.org, Jul 12 2010

Mergedinto: 48240
Status: Duplicate

Comment 8 by rsesek@chromium.org, Jul 12 2010

Labels: -OS-Linux
Mergedinto: -48240
Status: Available
This is for Mac, too. Unmerging.

Comment 9 by dhw@chromium.org, Jul 12 2010

Labels: PlatformParity
 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.
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.
Labels: -HelpWanted
Status: Started
Status: Fixed
Labels: Verifier-Deepakg
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
------------------------------------------------------------------------

Status: Verified
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.

Comment 23 by krtul...@gmail.com, Aug 30 2010

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

The Linux version of this bug is  Issue 48240 
Project Member

Comment 24 by bugdroid1@chromium.org, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 25 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-UI -Feature-TabStrip -Mstone-7 Cr-UI-Browser-TabStrip M-7 Cr-UI
Project Member

Comment 26 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment