Jaunty, drag and drop doens't work sometimes

Bug #382843 reported by Carroarmato0
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnome-do (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: nautilus

lsb_release -rd
Description: Ubuntu 9.04
Release: 9.04

apt-cache policy nautilus
nautilus:
  Installato: 1:2.26.2-0ubuntu2
  Candidato: 1:2.26.2-0ubuntu2
  Tabella versione:
 *** 1:2.26.2-0ubuntu2 0
        500 http://be.archive.ubuntu.com jaunty-updates/main Packages
        100 /var/lib/dpkg/status
     1:2.26.2-0ubuntu1 0
        500 http://be.archive.ubuntu.com jaunty/main Packages

Sometimes drag and drop of files doesn't work in Jaunty. I don't know why.

To bypass this issue, I'd have to manually copy-paste the files to the destination.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

 * Is this reproducible?
 * If so, what specific steps should we take to recreate this bug?

 This will help us to find and resolve the problem.

Changed in nautilus (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Carroarmato0 (carroarmato0) wrote :

It happens nearly every day, thought I have no idea what could cause this bug.

I'm not even sure if it's linked to nautilus itself.

If you could elaborate a good way to monitor and log strange nautilus behaviour I'd be glad to run the tests until I encounter the problem.

Revision history for this message
LaurenceEffect (lb-aysgarth) wrote :

I've had the same problem - it doesn't happen all the time, but it does happen more than 50% of the time.

As described by Carroarmato0, when trying to move files from one place to another (typically copying photos off a memory card, but also when moving files around on the same drive), the user drags the files from the source window to the destination window, the cursor changes to a dragging file icon, with a + (copy to) as normal, however when the mouse button is released, the cursor returns to normal (as if the file had been dropped), however the file doesn't get copied or moved.

Whilst playing with it in order to describe it properly for this bug report, I have found that whether the drag/drop works or not depends on the distance from the bottom of the window to where the file is dropped. If the file is held over the bottom 150 pixels (or so, distance estimated) of a Nautilus window, then the cursor will always show a + (copy icon), however if the file is held higher up, the section of the window (or directory underneath the cursor) gets highlighted and the file is moved as normal as shown in the screenshot.

In the window on the left, I'm dragging "temp3" onto "temp2" which is towards the bottom of the window. Note that "temp2" has not highlighted. Also, the cursor has not been shown correctly by the screenshot - at this point, it was a gripping hand with a +. In the window on the right, I'm dragging "temp3" onto "Personal", here "Personal" is highlighted to tell me that the file will be moved to there, as is the border of that panel of the window. At this point, I again had the gripping hand cursor, however this time it had an arrow to say it was going to move the file there.

This bug appears to be unrelated to which view mode (icons, list, compact) the window is in.

Revision history for this message
Carroarmato0 (carroarmato0) wrote :

I have discovered that using Gnome-DO also causes some annoyances. When Gnome-Do starts it takes a little less than half my screen space (invisible). That means that drag-and-drop behaviour is changed or ignored when draging a file to the lower part of my screen where the Gnome-Do panel resides.

Although this too is a bug, I believe it's not related to this one.

@LaurenceEffect: are you too using Gnome-Do?

Revision history for this message
LaurenceEffect (lb-aysgarth) wrote :

I am using Gnome-Do, in "Docky" mode. I think you might be onto something there - the effect I described happens below a certain point on the screen, no matter where the window is (ie, if the window's high up, you can drag/drop to any part of it, if it's low down, you can't drop onto it at all). And if I close Gnome-Do then I can drag/drop to any part of the screen.

Well done, I think you've found the problem! I have changed the bug details to mention the gnome-do package as well.

affects: nautilus (Ubuntu) → gnome-do (Ubuntu)
Revision history for this message
Carroarmato0 (carroarmato0) wrote :

Yes, I too am using Gnome-Do in Docky mode. I discovered this while switching on and off Compiz to test composit mode with metacity itself. When disabling composite effects, I noticed the bottom side of my screen turned black until metacity kicks in. The black part of the screen is related to the screenspace that Gnome-Do claims for its own.

Changing package hint to Gnome-Do. Either Gnome-Do should take less screen space, or find another way to keep drag and drop functionality.

Revision history for this message
Jason Smith (jassmith) wrote :

It's been fixed in bzr for a while now

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-do - 0.8.2+dfsg-1

---------------
gnome-do (0.8.2+dfsg-1) unstable; urgency=low

  * New upstream release
    + No longer uses a plugin repository. Fixes many plugin-
      related issues. (LP: #343096, LP: #330025, LP #345001)
    + No longer blocks on "About Do" (LP: #361679)
    + Reacts correctly when a Composite manager is enabled/
      disabled at runtime. (LP: #346347, LP: #390150)
    + Fixes for space reserved by Docky blocking drag and
      drop operations. (LP: #354729, LP: #347052, LP: #382843)
    + Properly sets "Hidden" key on autostart files in response to
      "Start on login" option. (Closes: #526023) (LP: #369988)
  * debian/patches/10_application_search_path:
    + Drop; included upstream
  * debian/patches/10_sk_translation_update:
    + Import sk translation update from Debian BTS.
      (Closes: #531779)
  * debian/patches/11_fix_autostart_when_directory_does_not_exist:
    + Patch from upstream. Fixes the "Start on login" option when the
      ~/.config/autostart directory does not exist. (LP: #393729)
  * debian/control:
    + Update standards version to 3.8.2; no changes required.
    + Add libtool to Build-Depends; required for autoreconf.
    + Add Recommends: on new gnome-do-docklets package.
  * debian/gnome-do.1
    + Fix spelling: GNOME-Do => GNOME Do.
    + Miscelaneous lintian fixes; NAME section, escaping minus signs with \-
  * debian/copyright:
    + Update for new copyright holders.
    + Minor update to DEP-5 format

 -- Steve Kowalik <email address hidden> Wed, 12 Aug 2009 07:36:56 +0100

Changed in gnome-do (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.