The call stack when a new find-on-page result is found:
FindTabHelper::HandleFindReply
Browser::FindReply
content::WebContentsImpl::NotifyFindReply
content::FindRequestManager::NotifyFindReply
content::FindRequestManager::OnFindReply
content::WebContentsImpl::OnFindReply.

FindTabHelper::HandleFindReply notifies all observers about the result, so the fix should not be higher than that. I'd suggest a fix in FindTabHelper or WebContentsImpl.

Thanks for filing the issue, Followed the below steps:

1) Navigated to a wiki page, which has text which overlaps the find it search box when invoked
2) Searched for a text using the find it 

Observed that find bad showed the result correctly with out any issues. Can you please help us with a screen case so that we can triage the issue better.

This was tried on Stable build 60.0.3112.101 on a Windows 10 HiDPI and Mac 10.12.6 Mac Retina.

Thanks.!

https://youtu.be/M8mjZkRrndc a video showing the bug in action. Latest Chrome (60.0.3112.101).

Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

There is already a pull request to solve the issue, https://chromium-review.googlesource.com/c/620652/

Confirmed this issue also affects ChromeOS pixel devices.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/60110d69728e93dd4015ecd6b07f1fe19195d219

commit 60110d69728e93dd4015ecd6b07f1fe19195d219
Author: Anton Suslov <afakeman@yandex-team.ru>
Date: Tue Sep 12 12:42:55 2017

Account for DPI/Screen coordinate discrepancy for find in page selection box.

On systems that use-zoom-for-dsf with HiDPI find bar would shift incorrectly
when obscuring search results due to WebKit returning selection box in
screen coordinates without converting them to display coords.

In order to write a proper test, we'd have to check if find bar still
overlapped the selection box, but there is no way to know where the box is
without somehow using FindReply message, which was sending wrong coordinates.

Bug: 755958
Change-Id: Ifb1c1615aa019c876c3c9488b659b060ca8f8116
Reviewed-on: https://chromium-review.googlesource.com/620652
Commit-Queue: Trent Apted <tapted@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501246}
[modify] https://crrev.com/60110d69728e93dd4015ecd6b07f1fe19195d219/content/renderer/render_frame_impl.cc

Tested the issue on Windows-10(HIDPI) and Ubuntu 14.04(HIDPI) using chrome reported version #60.0.3112.101 and latest Dev M63-63.0.3213.3 by following steps mentioned in the original comment. Unable to reproduce the issue as per comment#3.

Not adding TE-Verified label as could not reproduce the reported version as well.

Thank you!

Fixing invalid statuses (no owner but not marked as available).