Ticket #81 (closed defect: wontfix)
crashes when starting drag&drop
| Reported by: | apaku | Owned by: | alwin |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | All | Version: | 0.8.x |
| Severity: | crash | Keywords: | |
| Cc: |
Description
Hi,
I'm using kdesvn 0.8.3 here and I can crash it by accidentally dragging a directory. This happens when I want to open a directory tree by clicking the small "+" but I hold the button for a millisecond to long and move the mouse. This doesn't happen on every such dir-opening, but it is safely reproducible by opening/closing directories very fast.
I already opened a bugreport in the debian bugtracking system and attached a backtrace there. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363433 for more information.
Andreas
STEPS TO REPRODUCE: quickly open and close directories in a not too small working copy.
Attachments
Change History
comment:1 Changed 7 years ago by apaku
- Owner changed from anonymous to alwin
- Status changed from new to assigned
comment:2 Changed 7 years ago by alwin
very interesting. I can not resolve it at any working copy I have not depending on the size.
When I click on the "open"-sign and move the mouse it just starts dragging or (mostly) does nothing then open the directory. :(
And your last remark about that slow opening the repositories sounds interesting, too - my debug-builds have near to no differences to the optimized build.... I'll try to check it - I try to open the repository from aqbanking myself.
comment:3 Changed 7 years ago by apaku
Michael could also not reproduce this on his machine. Maybe it's like the bug regarding startup-speed of kdesvnd for the context menus, just happens on "slower" machines.
I have a Laptop with Centrino 1.4GHz running KDE here.
I'd also like to add, that when I need to reproduce it I end up "wildly clicking the directories" to make it happen. However the first time this happened I just opened the wrong directory and lets say a second later clicked the right one, eventually moving my mouse at the same time - boom.
Hmm, wait... I just tried with clicking 2 different directories _very_ fast and moving the mouse slightly - no crash.
Aaah, I think due to the fast clicking I moved the mouse away from the dir-decoration to one of the lines. So the mouse was over one of the vertical lines of the tree and in fact moving the mouse along one of these lines and rapidly clicking reproduces this.
Of course the last paragraph doesn't sound like the normal usage, but this is just for reproduction. It still happens from time to time during normal usage.
Andreas
comment:4 Changed 6 years ago by kgoeser
I can constantly reproduce the crash: I'm using a konqueror profile which splits the window into two parts. The left part is the directory containing all checked out repositories, which is "frozen" and linked to the right part. The right part has the the kdesvn part open.
Now to reproduce: Activate the left part, start right-mouse-button-dragging on a folder on the _right_ part (i.e. opening the context menu) and release the mouse button before the right part received focus / activation => crash! The crash does never (?) happen, if you activate the right part before dragging!
Note: shortly before the crash, on the lower right of the mouse pointer appears a folder icon, like kdesvn would start a drag operation for moving/copying a folder. However, I pressed the right mouse button, for in which case the menu should open.
I hope that helps :)
comment:5 Changed 6 years ago by alwin
- Keywords RESOLVED added
- Status changed from assigned to closed
- Resolution set to fixed
- Milestone set to 0.10.x
comment:6 Changed 6 years ago by apaku
- Keywords FEEDBACK added; RESOLVED removed
- Status changed from closed to assigned
- Resolution fixed deleted
I just tried 0.13.0 and still can reproduce this problem.
I also don't see any explanation of how this was fixed or in which version and the changelog doesn't mentioning any fix of this bugreport either. So maybe you just accidentally closed this one?
comment:7 Changed 6 years ago by alwin
I closed it 'cause I'd never got it reproduced. And I had re-worked drag&drop a lot and I think if there is a problem then it is more inside qt library itself.
I try to test it again.
comment:8 Changed 6 years ago by alwin
What I don't understand: when I have the kdesvn-part open in right pane, than there will never opens a context-menu. (when I have in both kdesvn open, too). Starting drag&drop only inside the right (kdesvn-part) pane, don't let crash. The kdesvn-part only opens a context menu if it is source and target of drag&drop (eg, an item should copied/moved inside repository or working copy).
if you have in both opened via KIO-urls, eg. ksvn+<proto>: this is NOT a kdesvn problem but konqueror. (Tested with kdesvn-0.13.0)
comment:9 Changed 6 years ago by apaku
But I don't use the kdesvn-part inside konqueror. I'm using kdesvn directly, I never tried using kdesvn-part in konqueror.
And no matter how fast I try I can't reproduce this within another KDE or Qt application (tried konqueror dragging files and also the qt3 dnd example).
comment:10 Changed 6 years ago by alwin
Works here perfect, too. (Debian) (Drag & Drop from kdesvn to konqueror, repository or working copy, perfect. Both directions. No idea anymore what should going wrong.
comment:12 Changed 6 years ago by kgoeser
(from the old bug tracker:) I can still reproduce it the same way I described above. I got you a stack trace of kcrash - however, the trace seems to reveal an infinite recursion. I shortened it for saving your web space ;)
http://www.alwins-world.de/programs/mantis/file_download.php?file_id=25&type=bug
comment:13 Changed 6 years ago by alwin
I see nothing in that trace what would help me finding a bug :(
comment:14 Changed 6 years ago by alwin
- Keywords FEEDBACK removed
- Status changed from assigned to closed
- Resolution set to wontfix
As long as I tried around, I can not find the problem. it seems to be a problem inside qt 3.x itself (timing problem), not sure.
'Cause porting to qt4 is more importing to me I'll no try to setup more workarounds.
