Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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"/>
<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
Worked in 4.0.3
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.
Sorry about the delay, just checking in - I use 'Optima 14' for the editor, I set it to 'default' and the issue is resolved.
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.
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.
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.
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?
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.
Aj, got it, thanks for the detail.
*** This bug has been marked as a duplicate of bug 15787 ***