GNOME Bugzilla – Bug 355756
random filename deletion, extra redraw of a file list
Last modified: 2008-02-26 23:03:20 UTC
There is a strange behavior that must have been introduced recently. When the 'browse for other folders' control is open, I have noticed an extra redraw of the file list. The dialog opens up with the file list visible but then repaints itself. The more troublesome behavior is that sometimes (cannot track when this happens) it will delete a filename existing in the 'Name' text entry with the repaint. The attached two videos illustrate the issue much better than this description. They are DivX avis and if you play them slowly, say with `mplayer -fps 4 file.avi`,you can see both problems nicely. This is gtk 2.10.3 on ubuntu edgy.
Created attachment 72690 [details] a video demonstrating the extra repaint.
Created attachment 72691 [details] a video of the filename being deleted after a dialog repaint. No keyboard input has been done.
Created attachment 73107 [details] [review] ideas There are some issues fixing this; the patch and explanation are about the current ideas I have. Some second opinions are appreciated :) I am not really sure yet where the extra repaint comes from, since it is not really visible on my machines. Setting the model to NULL already in the _map function for remap might help. If we don't, the "old" model will be shown first, and refreshed with another model later on. The "disappearing" file name issue is different. It looks like it's caused because browse_files_model_finished_loading() was called too early. The model was still empty and the attempt to select the "file name" failed. This caused the entry to be cleared. I introduced two fixes for this: * The UNIX backend needs to clear the is_finished_loading flag, if the stat info from a cached folder is cleared. * Have got_root_folder_cb() in the file system model emit finished-loading *after* it has created nodes for the files. Another cause for the disappering file name issue is the following: in shortcuts_row_activated_cb() we call shortcuts_activate_iter(), and after that gtk_widget_grab_focus on the list view. In the old code we assumed that shortcuts_activate_iter() would immediately load the new folder -- of course this is not the case anymore. So what actually happened was that _grab_focus was called on the tree view with the old folder loaded, which caused the first row to be selected, possibly overwriting the current contents of the entry, and on the next folder change the entry is cleared. The only way I see to overcome this is to postpone the focus grab to the point in time where the folder list view is loaded; in the patch there's a possible way to do this. Maybe there is a nicer way or a better solution. I was also wondering what the actual focus behaviour should be. I tried comparing with an older file chooser, but I guess this behaviour might have changed with the introduction of the location entry. If we could document this somewhere I can check if the whole thing complies with this policy.
Any update on this? The cleared filename entry is _very_ annoying; it happens frequently but not always when downloading a file in Epiphany. Bug 419737 is probably a duplicate of the filename part of this bug.
*** This bug has been marked as a duplicate of 419737 ***