I tried sublime.log_commands(True) and nothing was logged:
command: drag_select {"event": {"button": 1, "x": 1426.5, "y": 424.5}} command: drag_select {"event": {"button": 1, "x": 1401.5, "y": 431.5}} command: drag_select {"event": {"button": 1, "x": 524.5, "y": 938.5}}
where the middle line is the select where it happened.
Perhaps we can find a way to reproduce with more information? What type of hardware is this happening on? Always a trackpad, or using a real mouse? Are your machines set to HiDPI mode (retina for Mac)?
@wbond: I can reproduce fairly consistently on my current install. (It only takes a little bit of clicking back and forth to get the cursor to jump). On a clean portable build with the same project open, I canāt get it to happen, at least so far. I will try to fiddle with it some more to see if I can reproduce it.
The only package I see in common in all cases is Package Control, so it must be at fault. 
Can you get this behavior to occur on the top line of a document? I have seen similar to this frequently on my machine (windows and fedora) and it seemed to me that my mouse too sensitive vertically and I was actually moving my mouse slightly āupwardā thus going to the beginning of the line.
The border detection in that case does seem too sensitive for my taste and it happens somewhat often for me, but not too a disruptive extent
Retina Macbook here, happens with the trackpad, or with an external mouse, same thing on non-hdpi external display. Itās only once in a hundred clicks though.
I just did a fresh install and have done nothing but create a new text file with three line of text. Have been clicking around but no repro yetā¦
I have this issue. Two separate PCs running 3118 on Windows 10 Build 14379 both HDPI and with USB and wireless mouse. Happens frequently enough to cause unintentional errors in my code.
I can reproduce this on a new portable install with no packages. All I have to do is add my Preferences.sublime-settings file from my user folder:
{
"always_show_minimap_viewport": true,
"bold_folder_labels": true,
"color_scheme": "Packages/Color Scheme - Default/Monokai.tmTheme",
"font_options":
[
"gray_antialias",
"subpixel_antialias",
"directwrite"
],
"font_size": 10,
"ignored_packages":
[
"Vintage"
],
"indent_guide_options":
[
"draw_normal",
"draw_active"
],
"line_padding_bottom": 1,
"line_padding_top": 1,
"overlay_scroll_bars": "enabled",
"trim_trailing_white_space_on_save": true
}
I can try messing with those settings to see if one is at fault.
Just reproduced it easily with just package control installed and these preferences:
{
"always_show_minimap_viewport": true,
// "color_scheme": "Packages/User/SublimeLinter/MonokaiGray (SL).tmTheme",
"enable_tab_scrolling": false,
"ensure_newline_at_eof_on_save": true,
"file_exclude_patterns":
[
"*.a",
"*.class",
"*.db",
"*.dll",
"*.dylib",
"*.exe",
"*.idb",
"*.lib",
"*.ncb",
"*.o",
"*.obj",
"*.pdb",
"*.psd",
"*.pyc",
"*.pyo",
"*.sdf",
"*.so",
"*.sublime-workspace",
"*.suo",
"._*",
".DS_Store"
],
"folder_exclude_patterns":
[
".svn",
".git",
"node_modules"
],
"font_face": "Input",
"font_size": 11,
"gpu_window_buffer": true,
"highlight_line": true,
"ignored_packages":
[
"Markdown",
"Vintage"
],
"indent_guide_options":
[
"draw_active"
],
"show_definitions": false,
"tab_size": 4,
// "theme": "Hero Dark.sublime-theme",
"trim_trailing_white_space_on_save": true,
"typescript_auto_format": false,
"word_wrap": false
}
and while clicking around a .txt file:
test test test test test
{
testtest test test
}
testtest test test
For me it is the directwrite font option that seems to trigger it. But I thought that only applied to Windows? And anyways, it isnāt in your settings.
It is pixel perfect for me, I can find the vertical spot the cursor needs to be in in your example file on line 7 and every time I click there the cursor goes to the beginning of the line.
Yep, directwrite doesnāt matter in itself, I think it is a matter of how things are drawn to the screen. I canāt get it to work with no directwrite and font size 10 on my 1920x1200 display, but enabling directwrite causes things to be drawn differently enough that I can find that sweet spot. If I turn off directwrite and up the font size to 11, I can cause the same behavior.
Ya, me too. Iām using a high-DPI tablet for input. By clicking on a line in tiny pixelwise increments top to bottom, I can get the jumping behavior every single time at a particular pixel position, near the vertical middle of the line.
I have this issue too. Hope it gets fixed fastā¦
Word selection is currently not relaxing.
I just replicated this too, with log_commands enabled and the x and y positions donāt look dodgy compared to the othersā¦ the last event in this log was the one that moved the cursor to the beginning of the line:
but, using that exact co-ordinate:
>>> sublime.active_window().active_view().run_command('drag_select', {"event": {"button": 1, "x": 240.5, "y": 135.5}})
causes the cursor to go to the start of the lineā¦ 1 in 100 timesā¦
so it is a problem with the drag_select commandā¦
also, tweaking the co-ordinates slightly, it still does the same thing, exceptā¦ 100% of the time!..
>>> sublime.active_window().active_view().run_command('drag_select', {"event": {"button": 1, "x": 241.5, "y": 135.6}})
but, what is odd, is that the original co-ordinates also now reliably reproduce itā¦
(This is on Windows 7 x64, ST3118, font_size 11, dpi_scale 1, maximized window, (relevant) monitor size 22", monitor res: 1920x1080)
Okay, I will try with a clean install, and if I can reliably reproduce it, I will share my ST data folder (without the license file ofc) 
I reliably replicated on a completely clean install (not even Package Control installed), default window size with font_size 11 the only preference, but apparently the session doesnāt help, because restarting ST and then running the same drag_select command that was reliably failing before the restart worked againā¦
The co-ordinates were in the middle of the line, not the end, in case it helps. Also, with a slightly different x pos, but the exact same y pos, it was also going to the beginning of the line.
EDIT: unfortunately, I forgot to check what is returned by the view.window_to_text((event["x"], event["y"])) API.
+1
I have this problem as well since 3118 (OS X 10.11.5). I had to go back to 3117 since this happens quite often and is a total showstopper.
Got to reproduce it consistently in one occurence. Whenever the y coordinate was >=161 and <162, the caret would jump to the beginning of that line.
I could, however, only reproduce this in one file. Not on any other and not even when I copy the entire fileās content into the clipboard and open a new file. Hereās a recording:
Edit: Also note that it didnāt matter whether I was in windowed or fullscreen or if the sidebar was visible or not. If I enable the tab bar, the special y coordinate becomes 285.x.
This has now been reported at https://github.com/SublimeTextIssues/Core/issues/1273