I've never used tiling so naturally I would never see that bug. I did see a similar result, where if I drag gnome-disks to the top edge it doesn't always go all the way there. For my purposes that's OK, but probably not for someone using tiling. That margin always exists, it's what becomes the black border without this fix, it's just transparent now. Perhaps GTK3.16 and later drop the margin when a window is tiled if and only if the WM is not recognized as a compositor? How do mutter/shell/muffin/cinnamon deal with this? BTW, in gtk3.20, "window.frame" changes to "decoration." OK, the question this raises if a fix for both issues at once is not found is this: which is worse, ugly borders on CSD apps or CSD apps that don't tile all the way to the edge? Right now the choice is one or the other, and I suspect that will be different from user to user. If the compositing support is deemed more important, than it could be merged now and the tiling worried about later. Also, compiz as currently used by Ubuntu is enough of a problem with gtk3.16 and later that not fixing this could spur Ubuntu devs to speed up the transition to Unity 8 and drop compiz support altogether for flavors like Ubuntu MATE. I doubt they would change course now and do this for 16.04, but there is the real chance that 16.04 will be the last time the flagship "ubuntu" version uses compiz and it is an LTS release. Thus, a strong reason to try and get things right by fixing both bugs. Not merging the compositing fix increases the risk that it will fall by the wayside like it did last Spring. I don't know how to work with bzr at all other than cut and paste the code to clone the repo locally-and with something the side of compiz, that creates bandwidth problems on my connection. Thus the local application of patches to downloaded tarballs-and any mistakes that might have created last summer. On 2/6/2016 at 6:30 AM, "Alberts Muktupāvels"