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 148732 - cursor movenmet is not correct in gedit when I type Arabic text.
cursor movenmet is not correct in gedit when I type Arabic text.
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
2.5.x
Other Linux
: Normal normal
: Small fix
Assigned To: Behdad Esfahbod
gedit QA volunteers
Depends on:
Blocks:
 
 
Reported: 2004-07-28 22:00 UTC by Munzir Taha
Modified: 2007-05-03 01:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix (2.60 KB, patch)
2006-08-30 21:59 UTC, Behdad Esfahbod
committed Details | Review

Description Munzir Taha 2004-07-28 22:00:29 UTC
Type two lines of Arabic text, press the right arrow or Home keys to go to the 
beginning of the second line. Press the right arrow again to go to the last 
character of the first line. The cursor doesn't behave properly. It jumps to 
somewhere to the middle of the firs line!! i.e. the cursor never goes through 
the last characters of the first line.
Comment 1 Munzir Taha 2004-07-30 15:36:17 UTC
I tried this with Gnome gedit 2.6.2 
gtk is 2.2.4 
on a Mandrakelinux 10 
 
I tried to find testtext to test whether it's a gtk or gedit problem but I 
failed to find it :( 
 
I am sure Mr. Taylor will do the missing part ;) 
Comment 2 Owen Taylor 2004-07-30 15:45:38 UTC
As indicated on IRC, I couldn't reproduce with GTK+-2.4 or newer.
Unless it can be reproduced with current versions of GTK+, the bug
should be closed.
Comment 3 Paolo Maggi 2004-07-30 15:50:42 UTC
Munzir: please, try to reproduce it with gtk-demo (GtkTextView).

Could you please try to reproduce it with gtk+ 2.4.x?
Comment 4 Owen Taylor 2004-07-30 15:51:43 UTC
gtk-demo doesn't have wrapping on, so it apparently isn't suitable for
reproducing this bug.
Comment 5 Munzir Taha 2004-08-06 02:11:25 UTC
I compiled glib-2.5.0 pango-1.5.1 atk-1.6.1 (1.7 couldn't be downoaded from 
the gtk.org) gtk+-2.5.0 and was able to reproduce the bug with gtk-demo but 
with 3+ lines not 2 lines as tested in gtk-2.2. We are improving... ;) 
 
I also noticed that the cursor jumps to different places sometimes even with 
the same text! 
 
Also note that this gtk-demo version supports wrapping on. Thansk Owen Taylor 
for letting me compile gtk+ for the first time in my life ;) 
Comment 6 Paolo Borelli 2004-08-06 08:34:11 UTC
so I suppose I should move this to gtk+...
Comment 7 Munzir Taha 2004-08-06 10:28:39 UTC
I also tried testtext and could also reproduce this bug even with two lines. 
The behavior as I mentioned previously is not systematic. If you fail to 
reproduce it just make more lines, or try it more than once. 
Comment 8 Behdad Esfahbod 2005-10-13 09:40:26 UTC
Weird.  I can reproduce this with head.  Kinda tricky.  It's not
nondeterministic though.  Will try to look into it.
Comment 9 Behdad Esfahbod 2005-11-17 11:38:56 UTC
Ok, I valgrinded and secured the problem:

==26511==
==26511== Invalid read of size 1
==26511==    at 0x1BD60F7E: pango_layout_move_cursor_visually (pango-layout.c:1425)
==26511==    by 0x1BB422C9: gtk_text_layout_move_iter_visually
(gtktextlayout.c:3157)
==26511==    by 0x1BB59067: gtk_text_view_move_cursor_internal (gtktextview.c:4715)
==26511==    by 0x495281: (within /usr/lib/libgtksourceview-1.0.so.0.0.0)
==26511==    by 0x1BAA62B5: _gtk_marshal_VOID__ENUM_INT_BOOLEAN
(gtkmarshalers.c:1603)
==26511==    by 0x1BD8852E: g_type_class_meta_marshal (gclosure.c:567)
==26511==    by 0x1BD88B6C: g_closure_invoke (gclosure.c:490)
==26511==    by 0x1BD98A97: signal_emit_unlocked_R (gsignal.c:2487)
==26511==    by 0x1BD9986E: g_signal_emitv (gsignal.c:2120)
==26511==    by 0x1B9B75FA: gtk_binding_entry_activate (gtkbindings.c:525)
==26511==    by 0x1B9B8145: gtk_bindings_activate_list (gtkbindings.c:927)
==26511==    by 0x1B9B822D: gtk_bindings_activate_event (gtkbindings.c:1138)
==26511==  Address 0x1C57B984 is 12 bytes after a block of size 8 alloc'd
==26511==    at 0x1B909B71: calloc (vg_replace_malloc.c:175)
==26511==    by 0x1BDEE7F3: standard_calloc (gmem.c:111)
==26511==    by 0x1BDEE897: g_malloc0 (gmem.c:154)
==26511==    by 0x1BDEEF1E: g_slice_alloc0 (gmem.c:619)
==26511==    by 0x1BDFF7D1: g_slist_prepend (gslist.c:89)
==26511==    by 0x1BA8B5CE: _gtk_key_hash_lookup (gtkkeyhash.c:388)
==26511==    by 0x1B9B8217: gtk_bindings_activate_event (gtkbindings.c:1132)
==26511==    by 0x1BBB606B: gtk_widget_real_key_press_event (gtkwidget.c:3476)
==26511==    by 0x1BB573A7: gtk_text_view_key_press_event (gtktextview.c:3871)
==26511==    by 0x1BAA4257: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:83)
==26511==    by 0x1BD8852E: g_type_class_meta_marshal (gclosure.c:567)
==26511==    by 0x1BD88B6C: g_closure_invoke (gclosure.c:490)
==26511==


The offending line in pango is:

  while (vis_pos > 0 && vis_pos < n_vis &&
         !layout->log_attrs[start_offset + log_pos].is_cursor_position);

and this only happens on rtl lines.  Means: layout->log_attrs is not populated
for previous line if line is rtl.  Something like that.
Comment 10 Behdad Esfahbod 2006-08-30 21:59:46 UTC
Created attachment 71935 [details] [review]
fix

2006-08-30  Behdad Esfahbod  <behdad@gnome.org>

        Bug 148732 – cursor movenmet is not correct in gedit when I type
        Arabic text.

        * pango/pango-layout.c (pango_layout_move_cursor_visually): Update
        locally cached line properties upon line change.
Comment 11 Behdad Esfahbod 2006-08-30 22:00:57 UTC
Waiting for release team for permission to commit in pango-1-14.  Alternatively, can be committed after code freeze is over (next week.)
Comment 12 Behdad Esfahbod 2007-05-03 01:59:50 UTC
pango-1-14 is long not supported anymore... how fast...