12-04-2014, 05:31 PM
I've been having a minor problem for quite a while now (months, maybe years) with the Vuze Classic UI freezing up (but the program still running) in certain situations, which seem to be related to list-selection / scrolling.
The trigger seems to be an action that causes one of the torrent lists to scroll while interacting with it. The simplest and most reliable way to reproduce the problem:
Other operations, such as dragging to reorder list items, can also trigger a freeze, but the common thread appears to be the list attempting to scroll while another interaction is in progress. Scrolling without selecting/dragging is never a problem, it takes the two in combination.
In all other ways the application is still running — transfers continue and complete, RSSFeed Scanner continues to update, I can remotely add torrents or access the HTML Web UI and interact with it. It's just that the main GUI is frozen, or (if I minimize-and-restore the window) blank. I've left a frozen Vuze running for multiple minutes to see if it would recover (allowing all of the in-progress transfers complete, which they did), but it never comes back to life. The only way to recover is to kill Vuze / close the main window (which causes the window manager to show a "This window is not responding" dialog), then relaunch it.
I'm running the latest release (5.5.0.0) installed in my home directory, using SWT v4508, under Java 1.7.0_71 on Fedora 20 x86_64 (Linux v3.17.3-200.fc20.x86_64). Vuze is running on an Xvnc display, accessed over an SSH-tunnelled connection to port 5901. I've tried to rule out environmental factors as much as possible (including stripping all JAVA_ARGS from my startup script other than "-Dazureus.log.stdout=0") but nothing's made any difference.
This is not the GTK3 bug — I did add "export SWT_GTK3=0" to my startup script, but the problem still occurs.
It's kind of an esoteric issue, doesn't really impact functionality much, and the workaround of "just don't do that" has been pretty serviceable, so I've put off bringing it up until now. But the recent discussion of other Linux UI troubles reminded me of the issue, and I wanted to get it out there.
The trigger seems to be an action that causes one of the torrent lists to scroll while interacting with it. The simplest and most reliable way to reproduce the problem:
- Make sure the torrent list is longer than the visible area (needs to scroll)
- Select a row
- Shift-PageDown (or Shift-PageUp) to multi-select a set of torrents which extends out of the viewport (would cause the list to scroll)
Other operations, such as dragging to reorder list items, can also trigger a freeze, but the common thread appears to be the list attempting to scroll while another interaction is in progress. Scrolling without selecting/dragging is never a problem, it takes the two in combination.
In all other ways the application is still running — transfers continue and complete, RSSFeed Scanner continues to update, I can remotely add torrents or access the HTML Web UI and interact with it. It's just that the main GUI is frozen, or (if I minimize-and-restore the window) blank. I've left a frozen Vuze running for multiple minutes to see if it would recover (allowing all of the in-progress transfers complete, which they did), but it never comes back to life. The only way to recover is to kill Vuze / close the main window (which causes the window manager to show a "This window is not responding" dialog), then relaunch it.
I'm running the latest release (5.5.0.0) installed in my home directory, using SWT v4508, under Java 1.7.0_71 on Fedora 20 x86_64 (Linux v3.17.3-200.fc20.x86_64). Vuze is running on an Xvnc display, accessed over an SSH-tunnelled connection to port 5901. I've tried to rule out environmental factors as much as possible (including stripping all JAVA_ARGS from my startup script other than "-Dazureus.log.stdout=0") but nothing's made any difference.
This is not the GTK3 bug — I did add "export SWT_GTK3=0" to my startup script, but the problem still occurs.
It's kind of an esoteric issue, doesn't really impact functionality much, and the workaround of "just don't do that" has been pretty serviceable, so I've put off bringing it up until now. But the recent discussion of other Linux UI troubles reminded me of the issue, and I wanted to get it out there.
