Comment 26 for bug 455378

What progress has been made on rolling this behavior back? As far as I can see reading through the attached links the change behind this breakage fixes a non-problem (windows can always be moved and resized through the task list) but it breaks a large number of programs, including any window which tries to create itself at a size that would span two monitors, not to mention xemacs, blender and especially No Machine which reacts very, very badly to this. Assigning a keystroke to do the resize does not fix the problem; any window that then tries to tweak itself after resizing shrinks back to one monitor.

I've looked at the code which *apparently* affects this change (not being a compiz expert ... more than one thing may be involved here) and it really doesn't make sense - there was a clear setting which enabled/disabled this behavior, which was completely removed in favor of trying to be "smart". This was almost certainly not tested on multiple monitors as I can't imagine someone who'd seen what happens actually submitting it, much less making it into a release. I'm working on a change to roll this back on a personal build, but that will of course get out of sync as Compiz is updated.

Please, please, roll this back or roll forward a fix! This is close to a dealbreaker on a piece of software I've used successfully for years, and some of the comments made about this bug being a non-problem simply stagger me as clearly they haven't seen how badly this breaks Compiz.