Just guessing here, but could it be related to the (window border) theme? I haven't seen anything like this in all my years with mxflat.
On Wed, 31 Aug 2016 10:12:55 -0400 (EDT) Allin Cottrell <[email protected]> wrote: > On Wed, 31 Aug 2016, Andrew A. Adams wrote: > > >> Hi Geoff, > >> > >> Geoff Kuenning <[email protected]> writes: > >> > >>> I just had the resize happen again. It was definitely click, > >>> release, move mouse that caused the resize; the resize kept going > >>> even after the mouse button was released. Of course there's > >>> always the possibility of a small move between the click and > >>> release, but having the resize happen while the mouse is up > >>> is...disconcerting. > >> > >> FWIW, I have seen this behavior once in a while but not enough to > >> pin anything down. I hadn't thought to implicate sawfish until > >> your message. I'm using 3:1.12.0-1nano on Ubuntu 16.04. It's > >> maybe been going on for 1-2 months but that could be off. Maybe > >> it is correlated with using "full-featured" browser applications > >> in Firefox (eg gmail). Normally, I just click to break the action, > >> then fix the window size and move on. Next time it happens I'll > >> try to notice more details and reply to this thread, if the > >> problem is still open. > > > > I've seen this behaviour as well. It happens farily regularly, > > particularly when I'm using a touchpad rather than an external > > mouse. It has happened with any kind of page, not just the > > full-featured types. > > Me too. In particular with GTK3 applications that use "client side > decoration" (ugh!): clicking almost anywhere can initiate an unwanted > drag-to-resize, seemingly at random. In this (CSD) case it does seem > to be a sawfish issue: I don't see it if I run xfwm4 instead (but I > much prefer sawfish otherwise). > -- Sawfish ML
