Resizing Nautilus window using drag handle, handle seems to be "lost" after first drag

Hello,

Bug confirmed, BUT this is not a Nautilus bug.
The same behaviour is present for example in Totem.
So this should be a GTK issue, but I'm unsure about the package...
--> Need help here!

Note : this is not specific to the Human theme, all the other standard themes have the issue

A picture is worth thousands words, see attachment.

not confirming using the current intrepid versions, did you restart your session since the nautilus update?

I just did an upgrade/restart, and it's still present, but not quite as straightforward as I initially described (I don't think it changed, just my knowledge of it has). If you mouse all over the handle area and note what triggers the drag cursor and what doesn't it may be more evident. It does also seem to be a general GTK issue and not just Nautilus. I've noticed it in X-Chat GNOME now as well, but not Firefox, but I suspect not Firefox because it's not "really" a GTK app. I'm not entirely sure about this either, but resizing via the window border may "reset" the corner drag handle. Also, sometimes the drag handle will appear to work just fine a few repetitions in a row, but then break. My best advice for reproducing it is to just sit there with a Nautilus window and resize it over and over to completely different sizes, mousing over large portions of the drag handle each time to note where it does or does not register.

It may sound like a trivial bug, but more often than not it seems to break for me, and I tended to have to resize windows more than once in a row with the default Compiz configuration of only showing the blue rectangle outline of a window rather than resizing the actual window in-place.

not confirming the issue on intrepid, do you use the desktop effects option?

I do use Compiz, and it does seem to be the source of the problem. Using fusion-icon to turn it off and test resizing, I didn't seem to notice any problems.

reassigning to compiz

This bug was not present in hardy (compiz-core 0.7.4-0ubuntu7) on my machine. It appears in intrepid (currently 0.7.8-0ubuntu4.1).

Another observation: I don't observe this bug if I select the "Normal" method of resizing windows (using ccsm, or with gconf-editor at /apps/compiz/plugins/resize/allscreens/options/mode).

I observe the bug only when using one of the other resize modes ("Outline", "Rectangle" or "Stretch").

This appears to be a gtk issue rather than a compiz one since I'm able to reliably reproduce this under metacity (non-composite) using GEdit, System Moniter, and more. I was also able to reproduce it using the gtk.Window.resize function in pygtk.

I suspect that the GtkStatusbar widget isn't getting properly notified when windows are resized and so isn't always moving the "drag handle" to the new location within the window.

I confirm: it is NOT a compiz issue. I can reproduce this without compiz on Intrepid. With Hardy it is ok.

The symptom seems:
After the window size "jumps" by more than the size of the resize handle area, the area disappears. It reappears when the size is changed again slowly.

To reproduce this bug:
Resize the window and release the left mouse button when the mouse moves fast. Resizing like this by grabbing the window border is also affected. (as opposed to comment #6)

It's in Jaunty too.
I added this bug to project "One Hundred Paper Cuts". (great project!)

Thank you for bringing this bug to our attention.

But I'm unable to reproduce this in Karmic , As already pointed I can reproduce this in Jaunty , But not in Karmic, it seems fixed..

Until someone else is able to reproduce this in karmic , I'm marking this as incomplete.
A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10.

For further info about papercuts criteria , pls read > https://wiki.ubuntu.com/PaperCut

In Karmic alpha 3 this bug is still present.

As Ronan wrote in comment #2 it is not a Nautilus problem only. For example gedit is also affected.

In addition to my comment #13: I think, when the button is released while resizing a window, first the window gets redrawn for the last time AND AFTER THAT the mouse coordinates are read to determine where the resize area shall be, and after clipping this area to its usual region it disappears completely.

With a mouse most people will first stop moving before releasing the button and won't see the problem. And on systems with fast cpu/graphics the error will only be a few pixels. But on older Laptops with touchpads the problem is quite obvious. But because the symptom nearly seems random, many users might think their touchpads or movements are just too unprecise.

IMHO this bug would perfectly fit as one of the "One Hundred Paper Cuts", especially because one target of Karmic is to maximize usability on Netbooks.

@Oliver Joos , thanx for reminding ...

Yes, this is confirmed in Karmic Alpha3 , for some reason this didnt happen 1 month ago,
If i had noticed which update actually caused this to return , we could have been on track to solving this ! alas...

This is a really tricky bug!

I now notice that the pointer changes correctly , even on the second hover after the resize...

@Oliver Joos or anyone on Karmic. could you retest this?
Did anyone catch the update that causes the behavior to change?

With a Karmic alpha 4 Live-CD it is solved here, too!

Appears to be fixed now. I've tried all of the steps to reproduce mentioned in this bug with latest karmic and the resize handle always works correctly.

Upstream report is RESOLVED - FIXED