This issue is observed in all indic locales. Hence updating the summary accordingly.

Created attachment 108447 [details]
Screenshot of finding marathi text

I observe no problem.
Please test with latest stable and provide a sample document so I can test.

Created attachment 108503 [details]
mr_IN rendering in oowriter

Tested with following build at Fedora 21 using mr_IN locale. (VM environment)

आवृत्ती: 4.3.2.2.0+
बिल्ड ID: 4.3.2.2-5.fc21

Still observing the same issue. Please see attached latest screen-shot.
There is nothing specific about the input in mr_IN used here but some random input of 8-10 characters in the search text field. For e.g. ीावनूलेूीलेगवूीेूवै.

Copying these characters as it is would work fine. However if you add some more characters at succeeding places or select the whole string, the issue can be seen clearly.

(In reply to bbarve from comment #3)
> There is nothing specific about the input in mr_IN used here but some random
> input of 8-10 characters in the search text field. For e.g.
> ीावनूलेूीलेगवूीेूवै.
> 
> Copying these characters as it is would work fine. However if you add some
> more characters at succeeding places or select the whole string, the issue
> can be seen clearly.

Tried again with the characters you provided and it's fine. Maybe this is a Linux-only issue? Can you try on some Windows machine?

Not reproducible for me with LO 5.1.1.0.0+ built at home under Ubuntu 15.10 x86-64. As the reporter did, I used Lohit Devanagari font to do my tests.

Best regards. JBF

@bbarve
please give an update of this bug status using latest LibO 5.2.3.3

if bug is still there revert status to UNCONFIRMED
if bug is gone change it to RESOLVED WORKSFORME

status NEEINFO until then

Checked again with f25-

[bbarve@dhcp223-127 ~]$ rpm -qa libreoffice-core
libreoffice-core-5.2.6.2-6.fc25.x86_64

Following were the repro steps-

1. Launch oowriter
2. input following text in mr_IN in search bar - 'वाढदिवसाच्या हार्दिक शुभेच्छा'
3. select the last word i.e 'शुभेच्छा' by double-clicking it.
4. Observe the rest of the words in the search bar.

Actual result:
The rendering of the Marathi characters is affected as long as they are selected.

Expected result:
The rendering should be proper. 

The issue is clearly reproducible. Please refer attached screenshots.

Created attachment 134526 [details]
mr_IN_actual_rendering_f25

Created attachment 134527 [details]
mr_IN_expected_rendering

reproducible under Win7 x64 using LibO 6.0.0.0.alpha0+
Build ID: d7a2fd3e8262b8897ad06f01f25f46330e050e0c
CPU threads: 8; OS: Windows 6.1; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-07-20_08:26:15
Locale: it-IT (it_IT); Calc: group

status -> NEW
hardware -> All

Created attachment 138155 [details]
Incorrect rendering of devanagari text in Find box

Verified on Devuan Jessie
Version: 5.4.3.2
Build ID: 92a7159f7e4af62137622921e809f8546db437e5
CPU threads: 2; OS: Linux 3.16; UI render: default; VCL: gtk2; 
Locale: en-US (en_IN); Calc: group

Issue seems to happen with Short I vowel sign ि , which combines with consonant preceding it. Though certain other sequences also dont render properly - like the second word in search box (Browser written in Hindi)

Search box contains following text.
कंप्यूटिंग ब्राउज़र उद्धारक समर्थन हिंदी

This is not just about the search box. This happens with all the text boxes in LibreOffice. SO something to do with the selection overlays in general.

Created attachment 139946 [details]
Hindi text sample for previous image attached

Hindi text sample for previous image attached by me.

So, we looked at this in a local LibreOffice Hackathon and have found the relevant piece of code responsible for this. The selection offsets for consonants with a negative vowel offset are not being calculated correctly. Just dumping the notes here, so that even if we are not able to make it by the end of the hackathon, I or somebody else can pick it up sometime later.

I was testing this for Hindi word: प्रसारित which consists of 8 characters.

When this is selected in searchbox, the second last character is not selected.

The code is in Edit::ImplRepaint() in vcl/source/control/edit.cxx

Look for this loop:

        // selection is highlighted
        for(sal_Int32 i = 0; i < nLen; ++i)
        {
            tools::Rectangle aRect(aPos, Size(10, nTH));
            aRect.Left() = pDX[2 * i] + mnXOffset + ImplGetExtraXOffset();
            aRect.Right() = pDX[2 * i + 1] + mnXOffset + ImplGetExtraXOffset();
            SAL_DEBUG("i : " << i << ", rect: " << aRect);

The loop gives following output:

debug:2909:2909: i : 0, rect: 7x17@(2,4)
debug:2909:2909: i : 1, rect: 0x17@(9,4)
debug:2909:2909: i : 2, rect: 0x17@(9,4)
debug:2909:2909: i : 3, rect: 10x17@(9,4)
debug:2909:2909: i : 4, rect: 3x17@(19,4)
debug:2909:2909: i : 5, rect: 3x17@(22,4)
debug:2909:2909: i : 6, rect: 0x17@(25,4)
debug:2909:2909: i : 7, rect: 8x17@(32,4)


As one can see, there's a rectangle of 0x17 for i = 6. And there's a gap from 25 to 32. If we explicitly set it such that there's no gap, things work as expected.

Surely this is not the right solution but atleast something.

Character U+093F Devanagari Vowel Sign I is where it breaks.
In visual order the glyph for this character shows before the consonant it is placed after.

हिंदी   ह ि ं द ी

Reproduced. (But only when the text in search bar is selected)

Version: 7.1.3.2 (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 1; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

Fixed with by the fix for Bug 156377.