Dragging panels near screen edge

ash/wm/panels/panel_layout_manager.cc

Index: ash/wm/panels/panel_layout_manager.cc
diff --git a/ash/wm/panels/panel_layout_manager.cc b/ash/wm/panels/panel_layout_manager.cc
index c4ccd11a3d878a0cd6728166abfa487147f3bfeb..ece898588587dc0ee6a6855d54bffee38454043b 100644
--- a/ash/wm/panels/panel_layout_manager.cc
+++ b/ash/wm/panels/panel_layout_manager.cc
@@ -16,6 +16,7 @@
 #include "ash/wm/frame_painter.h"
 #include "ash/wm/property_util.h"
 #include "ash/wm/window_animations.h"
+#include "ash/wm/window_properties.h"
 #include "ash/wm/window_util.h"
 #include "base/auto_reset.h"
 #include "base/bind.h"
@@ -664,6 +665,7 @@ void PanelLayoutManager::Relayout() {
           ui::LayerAnimator::IMMEDIATELY_ANIMATE_TO_NEW_TARGET);
       panel_slide_settings.SetTransitionDuration(
           base::TimeDelta::FromMilliseconds(kPanelSlideDurationMilliseconds));
+      visible_panels[i].window->SetProperty(internal::kPanelAttachedKey, true);

[flackr, 2013/06/19 15:16:49]

Any panel that's being managed by panel layout manager should already have
kPanelAttachedKey set in order for the panel to have been reparented to the
correct layer. Is this not the case?

[varkha, 2013/06/19 15:49:22]

This was not the case when the panel was getting attached by setting size /
position from inside the app / API. While I have added some protection from
calling SetBounds redundantly, it is still possible to use API to force panels
to a particular position including position that it will attach to shelf. This
is why I have added this here - it avoids assertions (debug builds actually
terminate unless running under debugger) when trying to drag a panel after its
position has been "stolen".

[flackr, 2013/06/19 15:59:37]

It's my understanding that even if an application sets the bounds to be adjacent
to the shelf this would not actually attach the panel since that wouldn't change
the attached property and only the PanelWindowResizer can attach/detach panels.

[varkha, 2013/06/19 17:54:09]

The problem with dual screens was that SetBounds would reparent the window to a
root window that has more than 50% of the screen. This would call
PanelWindowResizer::FinishDragging an set the attached property to false. Then
the panel would get added to the panel layout manager of the other display and
slide_in logic would attach it to the shelf. Any drag after that would cause
reparenting logic to try and reparent it to the same parent that the panel
already has causing an assertion. Setting this property for panels that are
slid_in and are added to the launcher avoids it closing the loophole. With
http://crbug.com/251813 now open for discussion do you think this may stay as a
safeguard? It could alternatively be placed in line 658 limiting the case a bit.

[flackr, 2013/06/19 20:24:46]

When SetBounds is about to reparent the window, it should fire
ScopedWindowResizer::OnWindowHierarchyChanging to finish the drag before the
window is reparented. I suspect the problem might be that we compute the new
default parent before actually trying to reparent (which will then change the
attached property before the window is actually reparented). If this is the case
I suppose we could remove the window before asking for the default parent when
reparenting.

On 2013/06/19 17:54:09, varkha wrote:

       SetChildBoundsDirect(visible_panels[i].window, bounds);
       if (slide_in)
         layer->SetOpacity(1);