After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 537825 - Text cursor not erased when moved to new position
Text cursor not erased when moved to new position
Status: RESOLVED FIXED
Product: GtkHtml
Classification: Other
Component: Rendering
3.18.x
Other All
: Normal normal
: ---
Assigned To: gtkhtml-maintainers
gtkhtml-maintainers
: 541593 542009 734565 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-06-11 16:31 UTC by charltn
Modified: 2014-10-31 11:34 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
Screenshot (71.78 KB, image/png)
2008-11-12 18:43 UTC, hshane
  Details
When repainting, draw the cursor as part of the repaint (2.98 KB, patch)
2014-10-07 15:59 UTC, Owen Taylor
needs-work Details | Review
Screenshot showing simultaneously visible shadow cursor and real cursor (48.66 KB, image/png)
2014-10-30 08:56 UTC, Atri
  Details

Description charltn 2008-06-11 16:31:27 UTC
Please describe the problem:
Text cursor image remains on page when text cursor is moved.  If the blinking cursor is move by using the up arrow while the cursor is visible, the previous cursor image remains on the page.  Does not happen all of the time.  Also, small piece of the bottom end of the cursor remains in the line of text when typing.  When a redraw event occurs, the old images of the text cursor are erased, until it happens again.

Steps to reproduce:
1. Open Evolution.  Select "New" message.
2. Single click in the message body to position text cursor at the upper left. Hit "Enter" three times.
3. While the blinking text cursor is visible, hit the up arrow.  Blinking text cursor is now on the second line and the image of the old text cursor remains on the third line.


Actual results:
Image of the old text cursor is not erased.

Expected results:
The image of the text cursor in the previous position should have been erased.

Does this happen every time?
NO! But it can happen in both HTML and plain text mode.  It always happens using the instructions given.  But once a message is being typed the problem may go away for a short period.

Other information:
It is very annoying but not something that completely cripples the program.
Comment 1 Matthew Barnes 2008-06-11 17:07:41 UTC
At this point the solution to rendering issues is probably "move to WebKit".  GtkHtml's rendering engine isn't really being maintained anymore.
Comment 2 hshane 2008-11-12 18:43:40 UTC
Created attachment 122519 [details]
Screenshot

This is a screenshot of this effect. It occurs when editing text already entered in a new message when using the arrows.
Comment 3 Milan Crha 2014-03-14 13:47:20 UTC
*** Bug 541593 has been marked as a duplicate of this bug. ***
Comment 4 Milan Crha 2014-03-14 13:47:57 UTC
*** Bug 542009 has been marked as a duplicate of this bug. ***
Comment 5 Owen Taylor 2014-10-07 15:59:22 UTC
Created attachment 287974 [details] [review]
When repainting, draw the cursor as part of the repaint

When we repaint and the cursor is visible, draw the cursor to the
main cairo context we are using, rather than separately. This makes
sure that we draw the cursor on top of the content and clipped to
the redraw area, and thus preserve the shown/hidden state properly.

Some combination of redraw ordering or drawing outside the clipped
area caused the shown/hidden state of the cursor to be flipped
on redraw, causing a left-over cursor on next cursor move.
Comment 6 Milan Crha 2014-10-07 16:41:58 UTC
Review of attachment 287974 [details] [review]:

Apart of the two issues looks good, I'll commit a changed version of the patch, even I'm not able to reproduce the issue, somehow.

::: gtkhtml/htmlengine-edit-cursor.c
@@ +359,3 @@
 	if (clip_cursor (engine, x, y, width, height, &x1, &y1, &x2, &y2)) {
 		cairo_t *cr;
+		gboolean using_painter_cr;

can be used uninitialized

@@ +375,3 @@
+			y2 -= gdk_painter->y1;
+		} else {
+			gdk_cairo_get_clip_rectangle (cr, &rect);

build breaks on this line (as you pointed out on IRC)
Comment 7 Milan Crha 2014-10-07 16:48:00 UTC
Created commit e8a1711 in gtkhtml master (4.9.1+) [1]
Created commit 8d107ad in gtkhtml gnome-3-12 (4.8.5+)

[1] https://git.gnome.org/browse/gtkhtml/commit?id=e8a1711
Comment 8 Owen Taylor 2014-10-07 18:47:39 UTC
Further investigation reveals that this is a workaround for a bug in either the Xlib backend of cairo or the Intel driver. Running as GDK_RENDERING=image fixes the problem that I was seeing - which may or may not be the same as the original problem. The patch as applied is at least as correct as the original, however, and even a bit more efficient.
Comment 9 Matthew Barnes 2014-10-29 23:02:40 UTC
*** Bug 734565 has been marked as a duplicate of this bug. ***
Comment 10 Atri 2014-10-30 08:48:46 UTC
Issue persists despite updating to gtkhtml 4.8.5 containing above fix. I see both this issue as well the cursor disappearing issue [bug 734565] happen when composing emails. Versions installed:

libgtkhtml-4_0-0        | 4.8.5-1.1  | x86_64
libgtkhtml-editor-4_0-0 | 4.8.5-1.1  | x86_64
evolution               | 3.12.6-1.1 | x86_64
Comment 11 Atri 2014-10-30 08:56:43 UTC
Created attachment 289630 [details]
Screenshot showing simultaneously visible shadow cursor and real cursor

But the real cursor disappears from Line 7 onwards (the shadow cursor remains stuck to the same position.)
Comment 12 Milan Crha 2014-10-30 18:59:05 UTC
What is your gtk3 version, please? This depended on a change in gtk3 too, I think it's part of 3.14.1 or 3.12.1 or something, I do not recall. :(
Comment 13 Atri 2014-10-30 20:49:58 UTC
(In reply to comment #12)
> What is your gtk3 version, please? 

I am on gtk3 3.14.0. I will soon update to 3.14.1 and let you know if that solves it. Thanks for the quick reply.
Comment 14 Atri 2014-10-31 11:33:23 UTC
Thanks a lot, Milan, updated to 3.14.3 and the problem is solved, indeed.
Comment 15 Milan Crha 2014-10-31 11:34:58 UTC
Nice, thanks for the confirmation.