Bug 13950 - Cursor position steps to the right and gets out of sync when 'fi' is included in any text
Summary: Cursor position steps to the right and gets out of sync when 'fi' is included...
Status: RESOLVED DUPLICATE of bug 15787
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: 4.2.x
Hardware: Macintosh Mac OS
: Low normal
Target Milestone: master
Assignee: Cody Russell
Depends on:
Reported: 2013-08-13 09:02 UTC by Michael Thwaite
Modified: 2014-07-07 23:41 UTC (History)
1 user (show)

Tags: gtk
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Michael Thwaite 2013-08-13 09:02:00 UTC
Description of Problem: The cursor jumps to the right as you type the word 'confirm' into the following tag:

Steps to reproduce the problem:
1. Enter the following into an asp.net form:

<asp:LinkButton ID="lbDel1" runat="server" CommandName="Delete" OnClientClick="return ('Are you sure?');" text="del"/>

2. Edit the incorrect embedded javascript to add the function 'confirm' as in:
<asp:LinkButton ID="lbDel1" runat="server" CommandName="Delete" OnClientClick="return confirm ('Are you sure?');" text="del"/>

As you press c o n f all is well but when you hit the i the cursor jumps to the right and remains incorrectly positioned for the rest of the line.

Actual Results: Incorrect cursor position

Expected Results: normal cursor movement

How often does this happen? Always

Additional Information:
Worked in 4.0.3
Comment 1 Michael Thwaite 2013-11-16 13:08:52 UTC
This occurs in:

<%@ Register TagPrefix="pl" TagName="PaymentListing" Src="~/controls/PaymentListing.ascx" %>

At "fi" in TagPrefix

Is it detecting fi as a keyword of some sort? It occurs at any time you include fi in any text, e.g.


If you step the cursor through that, it jumps over fi after d.

Comment 2 Mikayla Hutchinson [MSFT] 2013-11-16 14:04:14 UTC
What typeface?
Comment 3 Michael Thwaite 2014-01-26 10:22:21 UTC
Sorry about the delay, just checking in - I use 'Optima 14' for the editor, I set it to 'default' and the issue is resolved.
Comment 4 Michael Thwaite 2014-01-26 10:26:54 UTC
It seems that any proportionally spaced font creates an issue, any fixed works fine.

I don't know how important this issue is now. I'm certainly fine with this work around.
Comment 5 Mikayla Hutchinson [MSFT] 2014-01-26 18:04:50 UTC
I suspect that the font has a ligature for 'fi' so the two letters are combined into a single glyph, and our text editor's caret movement doesn't handle that.
Comment 6 Mike Krüger 2014-02-12 01:23:39 UTC
Seems that ligature support isn't working.

pango layout get_cursor_pos seems to be ignoring them as well there seems no way to turn off ligatures.
Comment 7 Michael Thwaite 2014-02-13 11:23:15 UTC
Just an observation as I'm not sure I understand what a ligature is but, if I past in plain text iffiif, the cursor jumps over fi and treats it as one char _if_ I use a proportionally spaced font. All ok with monospace fonts.

Could the font selection dialog be filtered to monospace only?
Comment 8 Mikayla Hutchinson [MSFT] 2014-02-13 13:19:37 UTC

Fonts are essentially sets of glyphs (symbols) to be used for rendering characters. Some fonts contain ligatures, which are *stylized* glyphs to be used when rendering certain combinations of characters. So when rendering 'fi', if the font contained an fi ligature, you would use the fi glyph. If not, you would use the f glyph and the i glyph, as normal.

The issue here is that the text rendering library we use is not taking account of ligatures when computing caret movement, i.e. the caret is jumping over the whole glyph instead of realizing that it's actually two logical characters.

It's not really down to whether you use proportional or monospaced fonts, it's down to whether the font includes ligatures. Some fonts do, some don't.
Comment 9 Michael Thwaite 2014-02-13 13:29:34 UTC
Aj, got it, thanks for the detail.
Comment 10 Cody Russell 2014-07-07 23:41:30 UTC

*** This bug has been marked as a duplicate of bug 15787 ***