My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 135187: Resize handle too big for mouse use
4 people starred this issue and may be notified of changes. Back to list
 
Project Member Reported by Kusc...@chromium.org, Jun 29, 2012
I believe we increased the size of window resize targets for better touch use. However now when I use the mouse to resize a window, the target is way too big. The target should only be bigger for touch, not for mouse use.
Jun 29, 2012
#1 rby...@chromium.org
I agree this is problematic - eg. when there are overlapping windows it's surprising how far the resize target extends for mouse.

Sadrul, would it be hard to have the handle be small for mouse but larger for touch?  I know that's a little inconsistent but kuscher@ and I think it's the most natural UX experience (it's not so surprising with touch really the way it is for mouse).

If that's hard to do then we should explore other UX options.
Status: Assigned
Owner: sadrul@chromium.org
Jul 3, 2012
#2 sadrul@chromium.org
This is ... tricky. The code that does hit-detection (for both touch and mouse events) doesn't know about the event type. It can be fixed to know about the type, of course ... it's probably a lot of boiler-plate work. I will see if I can find a small fix.
Status: Started
Cc: jamescook@chromium.org ben@chromium.org
Jul 3, 2012
#3 sadrul@chromium.org
Ha ... simple fix possible: http://codereview.chromium.org/10703069/
Jul 3, 2012
#4 bugdro...@chromium.org
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=145359

------------------------------------------------------------------------
r145359 | sadrul@chromium.org | Tue Jul 03 12:55:17 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/ash/wm/frame_painter.cc?r1=145359&r2=145358&pathrev=145359

ash: Touch-optimize the window-resize region for touch-events only.

Both mouse and touch-events are possible in touch-optimized
UI. But for hit-testing, use touch-optimization only for
touch/gesture-events, and not for mouse-events.

BUG=135187
TEST=manually

Review URL: https://chromiumcodereview.appspot.com/10703069
------------------------------------------------------------------------
Jul 3, 2012
#5 sadrul@chromium.org
(No comment was entered for this change.)
Status: Fixed
Jul 3, 2012
#6 rby...@chromium.org
Nice, thanks for finding a simple fix!
Jul 23, 2012
#7 bhaves...@chromium.org
(No comment was entered for this change.)
Status: Verified
Jul 31, 2012
#8 rby...@chromium.org
This still seems broken.  Eg., put one window behind another and try clicking just outside the bounds drawn with the shadow.  You have to move quite far before you can actually focus the window in the back.

Sadrul, perhaps the logic you added has to also be applied in FramePainter::Init where there is similar use of kResizeOutsideBoundsSizeTouch? 
Status: Assigned
Jul 31, 2012
#9 rby...@chromium.org
 Issue 139836  has been merged into this issue.
Cc: glen@chromium.org saintlou@chromium.org
Aug 1, 2012
#10 rby...@chromium.org
From the code it looks like this only has an impact in --touch-optimized-ui mode, so not a regression for the common case.  It's OK to fix this in M23.
Labels: -Mstone-22 Mstone-23
Aug 9, 2012
#12 bugdro...@chromium.org
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=150870

------------------------------------------------------------------------
r150870 | sadrul@chromium.org | 2012-08-09T19:42:39.666581Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ash/ash_constants.cc?r1=150870&r2=150869&pathrev=150870
   M http://src.chromium.org/viewvc/chrome/trunk/src/ash/ash_constants.h?r1=150870&r2=150869&pathrev=150870
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/extensions/shell_window_views.cc?r1=150870&r2=150869&pathrev=150870
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/oak/oak_aura_window_display.cc?r1=150870&r2=150869&pathrev=150870
   M http://src.chromium.org/viewvc/chrome/trunk/src/ash/wm/shelf_layout_manager.cc?r1=150870&r2=150869&pathrev=150870
   M http://src.chromium.org/viewvc/chrome/trunk/src/ash/wm/frame_painter.cc?r1=150870&r2=150869&pathrev=150870
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/aura/window_unittest.cc?r1=150870&r2=150869&pathrev=150870
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/aura/window.cc?r1=150870&r2=150869&pathrev=150870
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/aura/window.h?r1=150870&r2=150869&pathrev=150870

ash: Use different hit-test outer-region for mouse and touch events.

The hit-region for windows need to be larger for touch events to allow
resizing windows easily, while continuing to use a smaller hit-region
for mouse-events.

BUG=135187

Review URL: https://chromiumcodereview.appspot.com/10854060
------------------------------------------------------------------------
Aug 9, 2012
#13 sadrul@chromium.org
(No comment was entered for this change.)
Status: Fixed
Aug 17, 2012
#14 rby...@chromium.org
(No comment was entered for this change.)
Labels: Iteration-62
Sep 10, 2012
#15 binch...@chromium.org
please provide the steps how to verify this.
Labels: PeedingDevFeedback
Sep 17, 2012
#16 bhaves...@chromium.org
Looks like changes not in. See attached image.
Reopening for Google Chrome	23.0.1268.0 (Official Build 157042) dev
Platform	2903.0.0 (Official Build) dev-channel
DSC_0314.jpg
2.4 MB   View   Download
Status: Assigned
Cc: tturche...@chromium.org kr...@chromium.org
Sep 17, 2012
#17 sadrul@chromium.org
Are you touching somewhere on the screen else when this happens? If so, then this is expected.
Sep 18, 2012
#18 rby...@chromium.org
M23 has branched.  If this needs to get into M23, please add a ReleaseBlock label and move it back.
Labels: -Mstone-23 MovedFrom23 MStone-24
Sep 18, 2012
#19 Kusc...@chromium.org
I am not touching anywhere else. This is a problem.
Labels: -MovedFrom23 -MStone-24 MStone-23 ReleaseBlock-Beta
Sep 18, 2012
#20 rby...@chromium.org
Interesting.  I can only repro this by touching somewhere else.  kuscher@ if you can repro, can you try turning on the 'Show HUD for touch points' flag?  Maybe chrome incorrectly thinks a touch is down somewhere for some reason.
Labels: Iteration-65
Sep 18, 2012
#21 Kusc...@chromium.org
After a restart I don't see this anymore which is confusing. I will play around a bit and see what I can do.
Sep 24, 2012
#22 sadrul@chromium.org
(No comment was entered for this change.)
Status: Started
Sep 25, 2012
#23 gir...@chromium.org
(No comment was entered for this change.)
Labels: -PeedingDevFeedback PendingDevFeedback
Sep 26, 2012
#24 Kusc...@chromium.org
And I can repro again. Sorry for not being able to give consistent repro :\ But it appears often enough to be an issue.
Sep 26, 2012
#25 rby...@chromium.org
Yep, I'm in this state again now - not sure what's getting me there, but after using the device for awhile it's pretty common to find it in this state.
Sep 27, 2012
#26 kar...@google.com
(No comment was entered for this change.)
Labels: -ReleaseBlock-Beta ReleaseBlock-Stable
Sep 27, 2012
#27 sadrul@chromium.org
Does this happen after resuming from suspend? I am beginning to think this might be caused by 150853.
Sep 27, 2012
#28 jamescook@chromium.org
(No comment was entered for this change.)
Cc: -jamescook@chromium.org
Sep 27, 2012
#29 rby...@chromium.org
Looks promising!  I just repro'd by restarting chrome, verify things are ok, then suspend/resume without touching the screen at all, now handle is too big.

So at least related to  issue 150853 , if not the same root cause.
Sep 27, 2012
#30 Kusc...@chromium.org
 Issue 152797  has been merged into this issue.
Cc: sky@chromium.org
Sep 27, 2012
#31 varunj...@chromium.org
 Issue 152797  has been merged into this issue.
Oct 1, 2012
#32 sadrul@chromium.org
(No comment was entered for this change.)
Blockedon: chrome-os-partner:12561
Oct 2, 2012
#33 rby...@chromium.org
(No comment was entered for this change.)
Labels: Iteration-66
Oct 5, 2012
#34 rby...@chromium.org
(No comment was entered for this change.)
Labels: -PendingDevFeedback
Oct 8, 2012
#35 Kusc...@chromium.org
What is the exact status here. Can we confirm this is a suspend/resume issue and more importantly it is fixed?
Oct 8, 2012
#36 sadrul@chromium.org
I think the fix for the suspend/resume was merged for M23 (https://code.google.com/p/chrome-os-partner/issues/detail?id=12561). Unfortunately I do not know what chromeos version has that fix. But I would be interested to know if this still reproduces in a version that has the chromeos fix.

Other than that issue, I could not find any other reason for this bug to happen.
Oct 9, 2012
#37 rby...@chromium.org
I tested with the following (which should have the touchscreen config fixes):
Google Chrome	23.0.1271.23 (Official Build 160542) dev
Platform	2913.68.0 (Official Build) dev-channel link

And this indeed seems fixed now.  I used to be able to reproduce this reliably (by suspend/resume) and now cannot repro.

So this bug is obsolete ("WontFix") - underlying issue addressed in issue chrome-os-partner:12561
Status: WontFix
Oct 9, 2012
#38 konigsb...@google.com
Reapplying labels
Cc: -jamescook@chromium.org sky@chromium.org
Labels: -PendingDevFeedback -ReleaseBlock-Beta ReleaseBlock-Stable Iteration-66
Blockedon: chrome-os-partner:12561
Nov 27, 2012
#39 rby...@chromium.org
(No comment was entered for this change.)
Labels: Restrict-View-Google
Mar 4, 2013
#40 rby...@chromium.org
(No comment was entered for this change.)
Labels: -Restrict-View-Google
Mar 10, 2013
#41 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-UI -MStone-23 M-23 Cr-UI
Sign in to add a comment

Powered by Google Project Hosting