GNOME Bugzilla – Bug 172277
scrolling on expose so that gedit +42 life.txt is istantaneous (blocked by gtk)
Last modified: 2020-11-24 09:57:46 UTC
Version details: 2.10.1-0ubuntu1 Distribution/Version: Ubuntu Hoary If I load up a file, scroll down a bit and click somewhere to place the cursor, the editor pane returns to the top of the file and I have to scroll back down again to get back to where the cursor is. Once this has happened once it doesn't seem to happen again until I reload the file or load another one.
This does happen only for big files, doesn't it? When we finish loading a file we move the cursor to the first line, so what I think it's happening is that you move the cursor before the file has completely loaded and when loading finishes it is moved back to the first line. I'll look into it
Created attachment 39706 [details] [review] patch let's see if this fixes the issue... I can't see why we needed to move the cursor to 0,0 in the first place.
Nah, it happens with any file that is longer than the window can display (i.e. there are scrollbars). When I scroll down and click in the window, the cursor doesn't move, but the window and scrollbars move back up to display the top of the file.
Unfortunately that patch doesn't seem to fix the problem. I noticed that the problem only seems to occur on standard text files and not e.g. C or Java files.
*** Bug 172047 has been marked as a duplicate of this bug. ***
Created attachment 39709 [details] [review] one more What about this one, does it solve the problem? please try applying only this one and if it still doesn't work try applying this one and also the one above: note with both patches applied the cursor will be placed at the end of the file by default, but if it solves the scroll issue means that we are on the right way. I'm pretty puzzled by the fact that I cannot reproduce the problem, I wonder what is the difference since I'm on ubuntu too...
Applying just the second patch fixes the problem for the first time a file is opened, if I open another file or the same file again without restarting gedit the problem is still exhibited. Applying both patches seems to fix the problem completely but when opening the first file the cursor is placed at the bottom of the file, subsequent file opens place the cursor at the top.
Created attachment 39718 [details] [review] one more patch before dinner One more guess... your help with testing is really appreciated, thank you! I tried moving the curson placement a bit earlier in the code, but I'm not sure it'll help. The patch aslo contains a separate scrolling related fix (without the patch, try to move at the end of a multipage file, hit ctrl+a and then ctrl+c... ouch!)
You're welcome, I'm glad I can help. Unfortunately this doesn't seem to make any difference and the behaviour seems to be exactly the same as in my last comment. The good news is I can confirm that the patch fixes the copy/paste problem for me as well.
which one of the two behavior you described before? :)
Sorry, I meant it behaves exactly as before i.e. both behaviours.
Created attachment 39756 [details] [review] another one after discussing this on irc it turned out that this may be something really subtle and I do not exclude that it can be a bug in gtk itself (the other possibility is that I'm just stupid). It looks like the scroll that we queue up on the first expose of a text view in order to move to a specific line, under some conditions (which are not clear) may end up being executed after the user clicks on the view, thus moving him back to line 0. with this patch I hope to at least fix the simptom even if it looks more like a bandaid than a proper fix: in the common case where the user doesn't specify a line with gedit +100 foo.txtx we don't queue the scroll. Does it work?
You'll be pleased to hear that it seems to have fixed the problem completely. :)
yay! gedit 2.10.2 fixed this for me! thanks a lot !!! lars
I'm using gedit 2.10.2 and I still have this problem. Version details: 2.10.2-0ubuntu1 Distribution/Version: Ubuntu Hoary It happens often with a file of about 10k lines. But it doesn't seem to be a question of time. I open it, wait some time (>20 seconds), scroll down, click in the text and... it shows the top of the file. The cursor is in the right place though. If I press the arrow keys, the line I clicked appears again. If I don't wait and scroll fast and click before the file has been completely loaded, then there's no scroll problem, but the file is marked as modified. And There's another little problem: when I copy, scroll far away, click, and then paste... sometimes it doesn't seem to paste anything, but later I realize that the text has been pasted somewhere else in the file. I can find it with undo-redo. This seldom happens but it does happen.
I cannot reproduce it on Ubuntu Hoary.
I have the issue here since hoary ...
can you attach a log obtained with "GEDIT_DEBUG=1 gedit"? Using gedit >= 2.10.3 because gedit_debug was broken (aargh!). Not sure that it'll be useful, but it will not hurt...
Created attachment 49685 [details] log with gedit 2.10.3 - "gedit file.txt" - scroll with the mouse using the scrollbar - click on a line somewhere on the middle of the page - the scrolling jumps to the top but the cursor is not moved
Are we sure this is not a GtkTextView or GtkSourceView problem? Are you able to reproduce it using "testtext" program in gtk+/tests and/or "test-widget" in gtksourceview/tests? BTW, it seems the version of gedit you used to produce the log still has a broken gedit_debug. If we send you the fixed gedit-debug.[ch] files, could you recompile and produce another log?
no issue with test-widget or testtext. I can get a log with the CVS if you want. Note that the breakge is specific to text file, with a rename of file.txt to file.c there is no issue
I now fixed the debugging output on CVS HEAD. At least I hope so :)
Created attachment 49713 [details] with the cvs
Created attachment 49715 [details] [review] evil hack seb, does this evil hack help?
no, still the same behaviour
Please, attach the result of: gconftool-2 --dump /apps/gedit-2 so we can test with the same configuration you are using. Which theme are you using? Please, attach also the file you are using to reproduce the problem? I really don't know why we are not able to reproduce it.
Created attachment 49729 [details] the config
For the record: I cannot reproduce in gedit 2.10.3 (GARNOME)
Paolo, I see the same behaviour in rawhide with gedit. I do not see it in testtext. What exactly is gedit doing when loading a file, it also moves the cursor to a specific position ? Can you try to reproduce the problem in testtext, by adding whatever gedit is doing after loading a file to testtext.c ?
Created attachment 49789 [details] [review] testtext patch Here is a patch to gtk testtext.c with which I'm able to reproduce the problem: just do ./testtext testtext.c, when you click on it the view scrolls to the bottom where the cursor originally is.
Created attachment 49823 [details] [review] gtk patch Here is a patch to gtktextview.c which seems to fix the issue for me. Seb, may you try it out? Patch explanation: when scroll_to_mark is called it queues a scroll to be flushed in an idle handler, however the idle handler itself is not added, the code assumes it will be already there. However this is not true when queuing the event from "expose" so we need to add the handler ourselves otherwise the scroll is delayed until such an idle is added (e.g. when the user clicks on the text). Note however that my patch may break some other assumptions in the scrolling code (which is quite complicated). Also note that I added the idle explicitely, while other code paths add it by calling invalidate(), which however also adds another idle, so I went with the minimal fix.
I've filed a separate gtk+ report with the above patch at http://bugzilla.gnome.org/show_bug.cgi?id=311728 so that we can keep this bug to keep track of the gedit side of things: if the patch is not suitable for gtk we may need to stop doing the scroll from the expose handler. A solution would be to do the scrolling from an (high prio) idle handler, this would work for sure, but would have the downside that the file would first be opened and then visibly scrolled to the curosr line.
Created attachment 49938 [details] [review] workaround patch Here is a patch which works around the current behavior of gtk: the result is less nice since you can see the view scroll, but at least it affects only the "gedit +42 foo.txt" and not the common case. This patch is intended for the 2.10 branch which depends on gtk 2.6 and also for future releases until gtk is fixed. Note that I also tried using an idle handler with HIGH priority, but it doesn't seem to work. Seb (sorry to bug you once more!) can you confirm that this fixes the issue? Both in the sense of making gedit +100 foo.txt work and in the sense of not screwing up the scrolling in the normal case.
the patches fixes the issues: * gedit scrolls correctly to the specified line instead of putting the cursor without scrolling * clicking on a line works as expected
pbor: since it seems we will have to wait more time for the patch against GtkTextView, I suggest to commit this patch in gedit (we will later add a check fo r the gtk+ version, so to enable the workaround only on broken gtk+ versions).
Ok, I committed the workaround patch. I'm leaving this bug open (changing the summary) so that we can improve the soloution when gtk gets fixed.
Since I don't think the gtk+ patch will be committed in time for gnome 2.12, I'm moving the target milestone.
Paolo: Can this be closed as OBSOLETE if gtk+ changes got in? Is the workaround in gedit still existing?
(In reply to comment #1) > When we finish loading a file we move the cursor to the first line, so what I > think it's happening is that you move the cursor before the file has completely > loaded and when loading finishes it is moved back to the first line. This seems to be still the case in 3.2 (with a 17MB text file).
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.