Bug 6197 - Mouse clicks in the editor sometimes moves the caret to the end of the line
Summary: Mouse clicks in the editor sometimes moves the caret to the end of the line
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: Trunk
Hardware: PC Linux
: Low normal
Target Milestone: ---
Assignee: Mike Krüger
URL:
: 6238 ()
Depends on:
Blocks:
 
Reported: 2012-07-19 10:22 UTC by Simon Lindgren
Modified: 2012-07-23 10:27 UTC (History)
2 users (show)

Tags:
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:
Status:
RESOLVED FIXED

Description Simon Lindgren 2012-07-19 10:22:05 UTC
Sometimes when I click on a line in the editor, the caret is not moved to the column where I clicked, but to the end of the line.

It seems to happen more often when clicking several times in quick succession, almost like a double click but on different lines, but that is not necessary - it happens on single clicks too.

Steps to reproduce:
Click around on some lines in a file.
Comment 1 Simon Lindgren 2012-07-23 09:34:52 UTC
Some additional info:

This issue is still present in b83531865b6e097a561c54c5a5f24000d456cd40.

I bisected the problem, and bc2ec0a4a80b1c4a1c3f70481823b7ca699463f7 seems to be the first bad commit. This commit has the commit message "[TextEditor] Applied work-around for font height problem." so it seems plausible that this commit introduced/exposed the bug.
Comment 2 Mike Krüger 2012-07-23 10:26:52 UTC
*** Bug 6238 has been marked as a duplicate of this bug. ***
Comment 3 Mike Krüger 2012-07-23 10:27:43 UTC
Setting another font exposed the problem.

/fixed