Incorrect drag ghost preview when an absolute-positioned child overflows the dragged element
Reported by
simon.ve...@gmail.com,
Mar 8 2018
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36 Example URL: https://codepen.io/simonverreydt/pen/KoKzVE Steps to reproduce the problem: 1. Drag the pink square over the yellowish area What is the expected behavior? The drag ghost shows B (purple strip) on top of A (pink square). What went wrong? The drag ghost only shows A (pink square) despite that the preview height is A + B Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 65.0.3325.146 Channel: stable OS Version: 10.0 Flash Version:
,
Mar 9 2018
Able to reproduce the issue on chrome reported version 65.0.3325.146 and latest chrome 67.0.3365.0 using Windows-10, Mac 10.12.6 and Ubuntu 14.04, as the issue break is in branch builds, hence providing manual bisect info. Bisect Info: ================ Good build: 64.0.3282.84 Bad build: 64.0.3282.85 https://chromium.googlesource.com/chromium/src/+log/64.0.3282.84..64.0.3282.85?pretty=fuller&n=10000 Change-Id: Ie792095806613cd1e6238bbb0d1b8335350ede01 Reviewed-on: https://chromium-review.googlesource.com/848499 @Chris Harrelson: Please confirm the issue and help in re-assigning if it is not related to your change. Thanks!
,
Mar 28 2018
Philip could you take this one?
,
Apr 4 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a323d69d16f705f9137f074ec50ee188684c9821 commit a323d69d16f705f9137f074ec50ee188684c9821 Author: Philip Rogers <pdr@chromium.org> Date: Wed Apr 04 20:52:59 2018 [PE] Correct drag image offset with positioned child DraggedNodeImageBuilder::CreateImage calculates the size and paint offset for drag images. After [1], the paint offset was the position of the dragged layout object in the enclosing layer's space. This was incorrect because a positioned descendant of the dragged object is painted in the drag image so the paint offset needs to be adjusted to the top-left of the bounding box of all content in the drag image (in the enclosing layer's space). This is easy to compute because we already have the bounding box in the enclosing layer's space, so this patch just uses the bounding box's location. [1] http://crrev.com/16b3d20c33 Bug: 820114 Change-Id: Idc634b3ddc79d0a47003362463b0c3d58f6f516c Reviewed-on: https://chromium-review.googlesource.com/996376 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Philip Rogers <pdr@chromium.org> Cr-Commit-Position: refs/heads/master@{#548189} [modify] https://crrev.com/a323d69d16f705f9137f074ec50ee188684c9821/third_party/WebKit/Source/core/clipboard/DataTransfer.cpp [modify] https://crrev.com/a323d69d16f705f9137f074ec50ee188684c9821/third_party/WebKit/Source/core/clipboard/DataTransferTest.cpp
,
Apr 4 2018
Simon, thanks for creating such a small testcase. Made it much easier to fix this issue. I think we've missed the boat for M66 so this will roll out in M67 (late May-ish). |
||||
►
Sign in to add a comment |
||||
Comment 1 by gov...@chromium.org
, Mar 9 2018Labels: Needs-Triage-M65