Comment #291 on issue 4 by [email protected]: Scrolling with some
scroll mice (touchpad, etc.) scrolls down but not up
http://code.google.com/p/chromium/issues/detail?id=4
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=9953
------------------------------------------------------------------------
r9953 | [email protected] | 2009-02-18 10:55:46 -0800 (Wed, 18 Feb 2009)
| 2 lines
Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab.cc?r1=9953&r2=9952
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab.h?r1=9953&r2=9952
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_strip.cc?r1=9953&r2=9952
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_strip.h?r1=9953&r2=9952
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/custom_frame_window.cc?r1=9953&r2=9952
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/custom_frame_window.h?r1=9953&r2=9952
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/event.h?r1=9953&r2=9952
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/root_view.cc?r1=9953&r2=9952
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/view.cc?r1=9953&r2=9952
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/widget_win.cc?r1=9953&r2=9952
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/widget_win.h?r1=9953&r2=9952
Solved 2 bugs which caused Chrome to maximize itself whendouble clicking,
either on the new tab button, on the closetab button or on a single
tab.BUG=2827BUG=3787The problem comes from the Windows event sequence upon
adouble-click (simplified here):1 - hit-test2 - mouse-down4 -
mouse-up/click5 - hit-test6 - mouse down7 - mouse up/double-clickThe 1st
hit-test is always performed correctly, returningclient for tabs and
non-client for the tab-strip (background).The 2nd hit test is not performed
correctly to avoid crashesin Chromebot from events being processed while
tabs are animating.Since we have no record of these crashes, Ben prefers we
keepthis special-case, even though we are responding incorrectlyto the
windows hit-test. So, when the tabs are animating wereturn a HTNOWHERE hit
which the caller translates into anHTCAPTION hit. This even though a
tab-control (new-tab/close-tab)may have been hit.The problem is that having
returned HTCAPTION to Windows defaultmessage handling, we get a NON-CLIENT
double-click event insteadof a standard one.To keep the behavior of the
second hit-test AND prevent theChrome window from maximizing, this change
simply declaresthe non-client double-click as handled when the tabs
areanimating.Another trick we pulled in the hit-test is to return
HTCAPTIONwhen a single tab is present. This allows the entire window to be
dragged but causes the context menu to be wrong and the windowto maximize
when double clicking on the single tab.The solution here is to correct
return a client hit for a singletab and, upon handling a client
single-click, delegate to thenon-client single-click default handler.
Review URL: http://codereview.chromium.org/21268
------------------------------------------------------------------------
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---
