after searching, clicking anywhere deletes file contents

Can confirm this happens, but for me it doesn't require searching for something.

The content seems to get deleted either when clicking the source view or when switching tabs.

Worst thing is that the files are autosaved and sometimes it's impossible to undo/revert.

Some sample terminal output when switching tabs:

[_LOG_LEVEL_FATAL 16:41:48.429255] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:48.429291] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:49.850369] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:49.850423] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:49.850494] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:49.850529] Scratch will not function properly.
[_LOG_LEVEL_INFO 16:41:51.496965] Document.vala:278: File "cmake_install.cmake" saved succesfully
[_LOG_LEVEL_FATAL 16:41:51.500007] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:51.500073] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:51.500171] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:51.500221] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:51.500506] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:51.500558] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:51.500649] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:51.500695] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:53.818643] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:53.818715] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:53.818812] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:53.818860] Scratch will not function properly.
[_LOG_LEVEL_INFO 16:41:54.223175] Document.vala:278: File "CMakeLists.txt" saved succesfully
[_LOG_LEVEL_FATAL 16:41:54.226267] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:54.226328] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:54.226381] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:54.226402] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:54.226528] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:54.226554] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:54.226612] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:54.226632] Scratch will not function properly.
[_LOG_LEVEL_INFO 16:41:54.650283] Document.vala:278: File "CMakeLists.txt" saved succesfully
[_LOG_LEVEL_FATAL 16:41:54.653378] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:54.653434] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:54.653513] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:54.653552] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:54.653754] [GLib] g_string_erase: assertion 'pos >= 0' failed
[_LOG_LEVEL_FATAL 16:41:54.653797] Scratch will not function properly.
[_LOG_LEVEL_FATAL 16:41:54.653881] [GLib] g_string_erase: assertion 'pos >= 0' failed
...

Removing lines 161 to 167 in Services/Documents.vala seems to fix this, though I'm not sure why.

Change was introduced in revision 1259: http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/revision/1259

I can't reproduce it. I am using latest trunk

This could be related to file encoding or other file-specific properties. Could you attach a fine with which the bug happens for you?

Can still reproduce this bug in latest trunk (rev 1272).

It only seems to happen when using the folder manager and file manager plugins. To reproduce open a file using one of those plugins and then click on the sourceview. The content should immediately disappear.

Opening files normally (i.e. not through one of those plugins) doesn't seem to cause this bug to happen.

Happens reliably with every text file from lp:scratch and lp:granite and files created using pantheon-files (again only when opened using one of those plugins)

Here's a screencast showing how to reproduce the bug. Note how the first to files are not erased.