GNOME Bugzilla – Bug 705464
Rename box displayed at wrong location when scrolling
Last modified: 2014-05-16 20:38:55 UTC
Exactly like bug 686322, except this time it's for Nautilus 3.9.3-git... If the file list (in icon view) is scrolled down, then the rename textbox is displayed in the wrong location. The more I scroll, the larger is the distance between the correct and actual position. (I wasn't sure if I should post a new bug report or reopen the old one...) nautilus 3.9.3.r47.g3a6053f gtk3 3.9.10.r50.ga4d9e92
I can reproduce this with today's nautilus master, pretty ugly bug, I think this should be a showstopper for nautilus 3.10
*** Bug 707415 has been marked as a duplicate of this bug. ***
As per my tests, this bug is caused by some component outside of nautilus (possibly a gtk+ change triggers it) because nautilus-3.8.2 that comes in my fedora 19 does not have the bug, while a compiled nautilus-3.8.2 that runs in jhbuild (where rest of packages have master or very up-to-date versions) do have the bug.
(In reply to comment #3) > As per my tests, this bug is caused by some component outside of nautilus > (possibly a gtk+ change triggers it) because nautilus-3.8.2 that comes in my > fedora 19 does not have the bug, while a compiled nautilus-3.8.2 that runs in > jhbuild (where rest of packages have master or very up-to-date versions) do > have the bug. I confirmed my suspicions, after an afternoon jhbuilding different gtk+ versions, I found the gtk+ commit that produces the bug, it's from 2013-05-07 and first appeared in gtk+-3.9.2, it's this: https://git.gnome.org/browse/gtk+/commit/?id=d22fd7223c75f4720ddb982c659efb0d8d7543c4 which is a non trivial patch from alexl that changes how gtk+ internal draw mechanism works. So maybe alex and other people who understand that code could look at the eel-editable-label.c draw function to check if it's in sync with those gtk+ draw changes? https://git.gnome.org/browse/nautilus/tree/eel/eel-editable-label.c#n1494 as that is the only thing I can think of as causing the bug.
Has a bug for this been filed against GTK? This is quite crippling.
Is there any chance of this being fixed by 3.10.1? It is kind of hard to recommend nautilus as a file manager (which I like to do) while you cannot reliably rename files ><.
*** Bug 710910 has been marked as a duplicate of this bug. ***
CC'ing alexl for the question on comment 4.
*** Bug 711302 has been marked as a duplicate of this bug. ***
Created attachment 258937 [details] [review] Fix rename entry position We need to not modify the cairo_t when we propagate up to the parent class as this affects where GtkLayout draws the child widgets.
Attachment 258937 [details] pushed as 481cf68 - Fix rename entry position
Pushed this to master and gnome-3-10, but we probably need a 3.10 release with this...
3.10.1 out
*** Bug 711502 has been marked as a duplicate of this bug. ***
*** Bug 730221 has been marked as a duplicate of this bug. ***