79417 2012-02-23 16:17:23 -0800 Drag image has a background when it shouldn't 2022-07-12 16:56:34 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) Mac (Intel) OS X 10.7 RESOLVED CONFIGURATION CHANGED P2 Normal --- 1 richard webkit-unassigned ap bfulgham davidbarr enrica oldest_to_newest 563634 0 128587 richard 2012-02-23 16:17:23 -0800 Created attachment 128587 Drag image with white background. In the attached reduced test case, when a draggable element appears inside of a positioned element, it retains a semi-opaque white background that is impossible to remove or change in any way. In fact, when you set a background with -webkit-drag, it appears that the -webkit-drag pseudo-element is contained within a parent element, because when you specify a background on -webkit-drag, it appears, but it appears inside of the outer white background. To work-around, if you add the declarations width: 100% and height: 100% to body, html, the white background disappears from the drag image. 564672 1 ap 2012-02-24 14:58:43 -0800 Testing in Safari on Mac, the resulting behavior looks pretty nice. Is this a significant problem? 564740 2 richard 2012-02-24 16:16:48 -0800 It's a bug, it should be fixed, in my opinion. It doesn't look nice at all when you're working in a situation where you don't want it. My test case doesn't represent a great many diverse use scenarios when it comes to drag and drop. Consider situations where you have something like a file icon in the Mac Finder, where you have an icon at the top and the text label below. With this bug, recreating that in a browser, the browser puts a big, ugly, semi-opaque square white box around the icon and the label, and you have no obvious way to get rid of it. I took me hours to figure out why there was a background on the drag image. When I originally observed the problem it was in a much more complicated web application, and I had no idea where it was coming from, I thought the webkit devs intentionally put the ugly white box in there. On a hunch, however, I compared my app to another one implementing drag and drop and observed the other app didn't have the ugly white box. So I went about the tedious process of slowly eliminating various bits of styles until I had isolated the issue. There is a work-around, and I was lucky to discover that work-around fairly quickly. These are the kind of things that make web development a nightmare. It is undocumented, unexpected behavior, and I can't imagine that the scenario of implementing drag and drop inside of a positioned element is really so fringe as to justify not addressing the issue. I certainly don't think it's a high priority issue in any way, but yes, I believe very strongly it is something that should be fixed. Thank-you for your time. 648797 3 davidbarr 2012-06-13 21:57:11 -0700 Confirmed with attached reproduction. Google Chrome: 21.0.1173.0 (Official Build 141861) canary OS: Mac OS X WebKit: 537.1 (@120155) WebKit Nightly Version 5.1.7 (6534.57.2, r120264) Given the nature of the workaround, this is almost certainly a bug. 1882753 4 bfulgham 2022-07-12 16:56:34 -0700 Drag background looks transparent in Safari 15.5. 128587 2012-02-23 16:17:23 -0800 2012-02-23 16:17:23 -0800 Drag image with white background. dragImage.html text/html 886 richard PCFET0NUWVBFIEhUTUw+CjxodG1sIHhtbG5zPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1s JyB4bWw6bGFuZz0nZW4tdXMnPgogICAgPGhlYWQ+CiAgICAgICAgPHRpdGxlPkRyYWcgSW1hZ2Ug QmFja2dyb3VuZDwvdGl0bGU+CiAgICAgICAgPHN0eWxlIHR5cGU9J3RleHQvY3NzJz4KICAgICAg ICAgICAgLyoKICAgICAgICAgICAgYm9keSwKICAgICAgICAgICAgaHRtbCB7CiAgICAgICAgICAg ICAgICB3aWR0aDogMTAwJTsKICAgICAgICAgICAgICAgIGhlaWdodDogMTAwJTsKICAgICAgICAg ICAgfQogICAgICAgICAgICAqLwogICAgICAgICAgICBwIHsKICAgICAgICAgICAgICAgIC13ZWJr aXQtdXNlci1kcmFnOiBlbGVtZW50OwogICAgICAgICAgICAgICAgLXdlYmtpdC11c2VyLXNlbGVj dDogbm9uZTsKICAgICAgICAgICAgICAgIHBhZGRpbmc6IDIwcHg7CiAgICAgICAgICAgICAgICBi b3JkZXI6IDFweCBzb2xpZCBibGFjazsKICAgICAgICAgICAgfQogICAgICAgICAgICBwOi13ZWJr aXQtZHJhZyB7CiAgICAgICAgICAgICAgICBiYWNrZ3JvdW5kOiBub25lICFpbXBvcnRhbnQ7CiAg ICAgICAgICAgIH0KICAgICAgICAgICAgZGl2IHsKICAgICAgICAgICAgICAgIHBvc2l0aW9uOiBh YnNvbHV0ZTsKICAgICAgICAgICAgICAgIHRvcDogMDsKICAgICAgICAgICAgICAgIGxlZnQ6IDA7 CiAgICAgICAgICAgICAgICByaWdodDogMDsKICAgICAgICAgICAgICAgIGJvdHRvbTogMDsKICAg ICAgICAgICAgfQogICAgICAgIDwvc3R5bGU+CiAgICA8L2hlYWQ+CiAgICA8Ym9keT4KICAgICAg ICA8ZGl2PgogICAgICAgIDxwPgogICAgICAgICAgICBEcmFnIG1lLgogICAgICAgIDwvcD4KICAg ICAgICA8L2Rpdj4KICAgIDwvYm9keT4KPC9odG1sPg==