Drag 'ghost' image not correctly created when parent and <img> child have position:relative
Reported by
pitaru.a...@gmail.com,
Apr 20 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36 Steps to reproduce the problem: 1. Create DOM with a nested <img> tag 2. Set CSS of both parent and child with position:relative 3. Set draggable property of child to false 4. Set draggable property of parent to true Code example: http://codepen.io/apitaru/pen/NNzzpO What is the expected behavior? Upon dragging, both parent and child elements should be included in the rendered 'ghost' image. What went wrong? Upon dragging, only the parent element is rendered in the 'ghost' image. Did this work before? Yes Previous version of Chrome, on my machine it was 49.xx but not sure which, sorry. Chrome version: 50.0.2661.75 Channel: stable OS Version: OS X 10.11.3 Flash Version: Shockwave Flash 21.0 r0
,
Apr 20 2016
,
Apr 21 2016
Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.4 using chrome version 50.0.2661.75 and canary 52.0.2713.0. This is regression issue broken in M49.Please find the bisect information as below Narrow Bisect:: Good: 50.0.2626.0 -- (official build 370259) Bad:: 50.0.2627.0 -- (official build 370581) CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/064741fcce814e441ee88f0230ca8066c4192049..89b8559b921b3a523dea4c7002cb79e2531579c3 Blink rolls:: https://chromium.googlesource.com/skia.git/+log/3425cbaee16a..76097f823598 https://chromium.googlesource.com/external/github.com/catapult-project/catapult.git/+log/c5f388bf5074..f53e90d4204f https://chromium.googlesource.com/webm/libvpx.git/+log/b520882f0eb2..c0307e6cea0f Possible suspect from the above CL:: https://codereview.chromium.org/1609983003 zmo@ Could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue. Thanks,
,
Apr 21 2016
I think this is actually caused by https://chromium.googlesource.com/chromium/src/+/8b1bccd2aa7837bcd52b217c6b32f2a507240374
,
Apr 22 2016
,
Apr 26 2016
Issue 606358 has been merged into this issue.
,
Apr 28 2016
I am having a similar issue with position: absolute on childNodes. https://jsfiddle.net/6paq0god/2/
,
Apr 28 2016
This bug was indeed my change in https://chromium.googlesource.com/chromium/src/+/8b1bccd2aa7837bcd52b217c6b32f2a507240374 This feature isn't really specified (it is, but you can do anything) and I thought just painting a single PaintLayer would be sufficient here. Unfortunately it looks like we regressed several sites. Today in LocalFrame::nodeImage we create a DragImageBuilder and paint just the enclosing paint layer. I think we should change that to paint the enclosing paint layer and all child layers too. @Chrishtr, would you be able to find an owner for this?
,
May 3 2016
Tien-Ren, sending this to you since pdr is out for a few weeks.
,
May 17 2016
Yea, it is because the inner positioned element is not a painting child of the outer element. I believe the old behavior was to paint everything in the DOM subtree, and the behavior after pdr's change is to paint only things in the painting subtree.
,
May 17 2016
Proposed fix: https://codereview.chromium.org/1982943002/
,
May 24 2016
Temporary fix - adding `transform: translateZ(0);` seems to force painting of descendents
,
May 24 2016
#12: Actually you can workaround with "position:relative; z-index:0;", which has similar effect as "transform:translateZ(0)" but costs less memory. Note that either approach change the stacking order of elements. FYI we just landed a fix on M53. The fix still doesn't match the old behavior 100%, but we believe it will work well in most cases.
,
May 24 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/40333ebebd01babf43339e66ee470679a9922244 commit 40333ebebd01babf43339e66ee470679a9922244 Author: trchen <trchen@chromium.org> Date: Tue May 24 23:22:45 2016 Drag images should paint descendants that are painting siblings of the dragged element DOM descendant of an element is not necessarily painting descendant of it. For example: <div id="A" style="position:relative; z-index:0;"> <div id="B" style="position:relative;"> <div id="C" style="position:relative;"> Although C is a child of B, C actually gets painted by A because B is not a stacking context. For drag image purposes, when B is dragged, the users expect to see the whole DOM subtree being dragged. In this CL we start painting from the nearest stacking context instead. BUG= 605119 Review-Url: https://codereview.chromium.org/1982943002 Cr-Commit-Position: refs/heads/master@{#395729} [add] https://crrev.com/40333ebebd01babf43339e66ee470679a9922244/third_party/WebKit/LayoutTests/fast/images/drag-image-descendant-painting-sibling-expected.png [add] https://crrev.com/40333ebebd01babf43339e66ee470679a9922244/third_party/WebKit/LayoutTests/fast/images/drag-image-descendant-painting-sibling-expected.txt [add] https://crrev.com/40333ebebd01babf43339e66ee470679a9922244/third_party/WebKit/LayoutTests/fast/images/drag-image-descendant-painting-sibling.html [modify] https://crrev.com/40333ebebd01babf43339e66ee470679a9922244/third_party/WebKit/Source/core/frame/LocalFrame.cpp [modify] https://crrev.com/40333ebebd01babf43339e66ee470679a9922244/third_party/WebKit/Source/core/paint/PaintLayerPaintingInfo.h [modify] https://crrev.com/40333ebebd01babf43339e66ee470679a9922244/third_party/WebKit/Source/core/paint/ReplicaPainter.cpp |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by cbiesin...@chromium.org
, Apr 20 2016Status: Untriaged (was: Unconfirmed)