New issue
Advanced search Search tips

Issue 792528 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Bug

Blocking:
issue 603386



Sign in to add a comment

Views: Constrained windows are draggable

Project Member Reported by rsesek@chromium.org, Dec 6 2017

Issue description

Chrome Version: 65.0.3286.0
OS: 10.12.6

What steps will reproduce the problem?
(1) --enable-features=SecondaryUiMd,ShowAllDialogsWithViewsToolkit
(2) Bookmark a website to the bookmarks bar
(3) Right click and choose "Edit" on the item in the bookmarks bar
(4) Click and hold on the "Edit Bookmark" dialog title
(5) Drag the mouse all around the screen

What is the expected result?
The constrained dialog stays put/attached to the place where it opened.

Or not, it's kinda fun that it doesn't, but this is definitely a behavior change from Cocoa.

What happens instead?
The constrained window is draggable.

Please use labels and text to provide additional information.


For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

 
Cc: bsep@chromium.org pkasting@chromium.org
Labels: Proj-HarmonyDialogs M-65 OS-Linux OS-Windows
Owner: tapted@chromium.org
Status: Assigned (was: Untriaged)
Summary: Views: Constrained windows are draggable (was: MacViews: Constrained windows are draggable)
This came up earlier in  Issue 500783 . There's logic to explicitly enable this behavior for tab-modal dialogs.

Of course, edit bookmark is window-modal and acts like a sheet on Mac, so you are quite right -- having that movable on Mac is super weird, and we need to fix it.

But it's also come up repeatedly in discussions with UX that they think having tab-modal dialogs movable is weird also. And since we've been refactoring dialogs away from rolling a custom titlebar, more have adopted this default titlebar behavior. We discussed "just disabling it" in meetings, but I think we lost track since there was no bug (thanks Robert for filing this!)

So the fix for these could be the same.

(or it could be
  Mac: tab modal and window modal not movable.
Other: tab modal not movable, window modal movable.


Comment 2 by bsep@chromium.org, Jan 10 2018

For the record: we wanted to disable dialog dragging on non-Mac platforms but we decided it was out of scope. If you need this for Mac, I think it's okay to make the change across all platforms.

Comment 3 by tapted@chromium.org, Jan 23 2018

Blocking: 603386
These Proj=MacViews bugs should probably be tracking for Phase 3 ( Issue 603386 ) - m66.
Project Member

Comment 4 by bugdroid1@chromium.org, Mar 23 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7ccf96e6fc17d994f4d5b654d209a2af64cfc922

commit 7ccf96e6fc17d994f4d5b654d209a2af64cfc922
Author: Trent Apted <tapted@chromium.org>
Date: Fri Mar 23 00:09:52 2018

MacViews: Disallow dragging of modals.

views::BubbleFrameView::NonClientHitTest() dutifully returns HTCAPTION
for points that hit the dialog title on non-bubble dialogs. This is
interpreted as a draggable region. But everyone freaks out when modal
windows are draggable, so disallow it.

Other platforms may still want window-modals to be draggable. But on
Mac these are sheets and dragging those is especially trippy.

Bug:  824422 ,  792528 ,  500783 
Change-Id: I2b9802e53cad7e762fc74d8b4ac73c4d82d067ba
Reviewed-on: https://chromium-review.googlesource.com/974810
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#545298}
[modify] https://crrev.com/7ccf96e6fc17d994f4d5b654d209a2af64cfc922/ui/views/cocoa/bridged_native_widget.mm

Labels: -M-65 Target-67 MacViews-Dialogs
tapted: is this Fixed now by the CL in #4?

Comment 6 by tapted@chromium.org, Mar 26 2018

Labels: -OS-Mac
For Mac, yes (primarily to address the extra-weird  Issue 824422  for window-modals).

Constrained windows (parent-modal) were at one time movable as well on *all* platforms (this bug). But when I tried Windows/Linux recently I couldn't reproduce this. Even though we definitely have 
reproduced it in the past (e.g. with http-auth). And the same code in NonClientHitTest() that returned HTCAPTION to trigger the move on Mac is still around. So I don't know what's going on :/. There may be a separate regression, or something I've missed.

Comment 7 by gov...@chromium.org, Mar 26 2018

Cc: ellyjo...@chromium.org
Labels: M-67
+ellyjones@, PTAL comment #6. Thank you.

Comment 8 by gov...@chromium.org, Mar 29 2018

Can this be marked as fixed per comment #6?

Comment 9 by tapted@chromium.org, Mar 29 2018

Status: Fixed (was: Assigned)
Sure. per #c6: this is fixed on mac. I don't know what's happening on Linux/Windows -- seems not to repro any more. (Feel free to reopen if it does).
Cc: viswa.karala@chromium.org
Labels: Needs-Feedback
Tested the issue on latest chrome 67.0.3390.0 using Mac 10.12.6, Ubuntu 14.04 & Windows-10 with steps mentioned below:
1) Launched chrome by enabling "SecondaryUiMd, ShowAllDialogsWithViewsToolkit", Bookmarked a website to the bookmarks bar
2) Right click and choose "Edit" in the bookmarks bar, Clicked and hold on the "Edit Bookmark" dialog title
3) Dragged the mouse all around the screen and observations are as follows:

Mac 10.12.6: Not able to drag "Edit Bookmark" dialog box on launching chrome with and without flags,
Ubuntu 14.04:Not able to drag "Edit Bookmark" dialog box, but on dragging it total chrome window got dragged on launching chrome with and without flags,
Windows-10: Able to drag "Edit Bookmark" dialog box on launching chrome with and without flags mentioned above.

@Trent Apted: Please find the attached screen cast of all three OS for your reference and please help in verifying the fix.

Thanks!
792528 - Mac.mp4
640 KB View Download
792528 - Linux.ogv
3.3 MB View Download
792528 - Windows.mp4
2.2 MB View Download

Sign in to add a comment