Windows shouldn't raise when initiating drag-and-drop |
||||||||||||
Issue descriptionVersion 54.0.2840.59 beta (64-bit) Platform 8743.65.0 (Official Build) beta-channel panther Firmware Google_Panther.4920.24.26 What steps will reproduce the problem? (1) Open 2 file windows, first SRC, then DST (2) Grab a file from SRC and drag to DST What is the expected output? I expect to grab the file and drop it without issue. What do you see instead? It is very often the case that the SRC window will cover completely the DST window when I start to drag. In other operating systems, this does not happen and I can drag an icon from one window to another without any raising happening.
,
Jan 10 2017
,
Feb 15 2017
It seems like this would involve changing window-focus behavior such that we send the background window the mouse-down event but don't focus it until mouse-up. @oshima what do you think?
,
Feb 22 2017
It's a bit tricky because we still should active a window on mouse click in normal case. One approach is to add a private API to not to activate by default, but let an app decide when to activate (or not). I'll aura/ash API, then yamaguchi@ can use it from files app to implement this behavior.
,
Feb 22 2017
> I'll aura/ash API, oops, it should read: I'll add aura/ash API, then...
,
Apr 5 2017
warx@, can you work on this? I can explain offline
,
Apr 12 2017
I had a chat with yamaguchi@ about the proposal of setActivateOnClick(bool) API. Attach his comments here for a record, "setActivateOnClick(bool) sounds enough. Assuming that there's already another API that the app can activate itself whenever it wants. What we'd do on our side (file_manager) is: 1. ask the window manager not to activate the window on click, but want all mouse events 2. ask window manager to activate the window whenever the app wants (for example, on mouseup event handler)."
,
Apr 12 2017
If we also want the same for dragging a file by touch, we'll also need to prevent activating a window at touch start.
,
Apr 12 2017
Consider naming it SetActivateOnPointer so that it's clear the function applies to activation by any pointer, not just mouse.
,
Apr 12 2017
For dragging by touch induced window activation, it will be handled by OnGuestureEvent here: [1]. I believe that is why OnTouchEvent is not implemented in FocusController? FocusController only deals with focusing window for two input events, OnMouseEvent with mouse_pressed and OnGestureEvent with gesture_begin and touch_points() == 1. I agree changing the name to SetActivationOnPointer to cover both cases. [1] https://cs.chromium.org/chromium/src/ui/wm/core/focus_controller.cc?q=focus_controll&l=139
,
Apr 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e47fb498dce50d65d9c3b55fafdbffbe50ab6920 commit e47fb498dce50d65d9c3b55fafdbffbe50ab6920 Author: warx <warx@chromium.org> Date: Fri Apr 28 02:20:14 2017 cros: allow aura window not considered activatable for pointer event Changes: Add a window property for set/get whether an aura window is considered activatable for pointer window activation. Modify CanFocusWindow in FocusRules to allow optional check for ui::Event. This is a stage one implementation for crbug.com/657525. BUG=657525 TEST=added test coverage Review-Url: https://codereview.chromium.org/2809073002 Cr-Commit-Position: refs/heads/master@{#467849} [modify] https://crrev.com/e47fb498dce50d65d9c3b55fafdbffbe50ab6920/ash/wm/ash_focus_rules.cc [modify] https://crrev.com/e47fb498dce50d65d9c3b55fafdbffbe50ab6920/ash/wm/ash_focus_rules.h [modify] https://crrev.com/e47fb498dce50d65d9c3b55fafdbffbe50ab6920/ash/wm/window_manager_unittest.cc [modify] https://crrev.com/e47fb498dce50d65d9c3b55fafdbffbe50ab6920/ui/aura/client/aura_constants.cc [modify] https://crrev.com/e47fb498dce50d65d9c3b55fafdbffbe50ab6920/ui/aura/client/aura_constants.h [modify] https://crrev.com/e47fb498dce50d65d9c3b55fafdbffbe50ab6920/ui/wm/core/base_focus_rules.cc [modify] https://crrev.com/e47fb498dce50d65d9c3b55fafdbffbe50ab6920/ui/wm/core/base_focus_rules.h [modify] https://crrev.com/e47fb498dce50d65d9c3b55fafdbffbe50ab6920/ui/wm/core/focus_controller.cc [modify] https://crrev.com/e47fb498dce50d65d9c3b55fafdbffbe50ab6920/ui/wm/core/focus_controller.h [modify] https://crrev.com/e47fb498dce50d65d9c3b55fafdbffbe50ab6920/ui/wm/core/focus_controller_unittest.cc [modify] https://crrev.com/e47fb498dce50d65d9c3b55fafdbffbe50ab6920/ui/wm/core/focus_rules.h
,
May 9 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/dc2e682ca5558e90332f8443e23539a04f436273 commit dc2e682ca5558e90332f8443e23539a04f436273 Author: warx <warx@chromium.org> Date: Tue May 09 18:39:31 2017 cros: Hook AppCurrentWindowInternal setActivateOnPointer with aura side api Changes: This is a follow up CL of https://codereview.chromium.org/2809073002/, which hooks AppCurrentWindowInternal setActivateOnPointer API with aura side changes. BUG=657525 TEST=none Review-Url: https://codereview.chromium.org/2854893004 Cr-Commit-Position: refs/heads/master@{#470390} [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/chrome/browser/ui/cocoa/apps/native_app_window_cocoa.h [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/chrome/browser/ui/cocoa/apps/native_app_window_cocoa.mm [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/chrome/browser/ui/views/apps/chrome_native_app_window_views_aura_ash.cc [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/chrome/browser/ui/views/apps/chrome_native_app_window_views_aura_ash.h [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/extensions/browser/api/app_current_window_internal/app_current_window_internal_api.cc [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/extensions/browser/api/app_current_window_internal/app_current_window_internal_api.h [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/extensions/browser/app_window/native_app_window.h [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/extensions/browser/extension_function_histogram_value.h [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/extensions/common/api/app_current_window_internal.idl [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/extensions/components/native_app_window/native_app_window_views.cc [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/extensions/components/native_app_window/native_app_window_views.h [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/extensions/shell/browser/shell_native_app_window.cc [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/extensions/shell/browser/shell_native_app_window.h [modify] https://crrev.com/dc2e682ca5558e90332f8443e23539a04f436273/tools/metrics/histograms/enums.xml
,
May 9 2017
Pass the issue to yamaguchi@
,
Mar 13 2018
Unassigned for triage in the Files app team. The remaining tasks for this feature is inside the Files app.
,
Mar 14 2018
weifangsun@ could you please triage?
,
Apr 12 2018
,
Apr 17 2018
,
Apr 17 2018
Checked with afakhry@ on prioritization, updated component, added to Files app backlog for future work. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by varkha@chromium.org
, Dec 1 2016Owner: tbuck...@chromium.org