Findbox should disappear once we reload and open new tab and come back to previous tab.

Count in the FindBar is not cleared when page get focus again.

The count in the FindBar should be cleared. and focus should be
on default position when we come back to page again after reload.
and when user select up or down in FindBar then selection should
happen and selection should move.
This have same behavior as FF.

BUG=88235

[Deepak, 2014-08-25 06:55:46]

PTAL.

1. Navigate to crbug.com and Ctrl+F and then search for a word (say: crash)
-DON'T dismiss the find-in bar.
2. Reload the page (by clicking on the reload button) and while the page is
loading switch focus to another tab.
3. For Step1 tab: After page is loaded (throbber stops spinning) focus back the
tab same tab again (step1).
4. Click on Up/Down arrow keys of Find-in page to continue the search.

I have purpose for removing the count from Findbar.
and when user select up or down in the FindBar then selection will happen for
the word present in FindBar.

[Finnur, 2014-08-25 10:50:42]

> This have same behavior as FF.

You are comparing apples and oranges here. FF doesn't do highlighting of
inactive matches but even so -- the active match *stays* highlighted in FF when
you switch away from a tab and come back to it (well, at least it does the first
time you do it -- I don't know why they chose to make it different the second
time you do it, weird).

But anyway, we should not follow that.

https://codereview.chromium.org/498133002/diff/1/chrome/browser/ui/find_bar/f...
File chrome/browser/ui/find_bar/find_bar_controller.cc (right):

https://codereview.chromium.org/498133002/diff/1/chrome/browser/ui/find_bar/f...
chrome/browser/ui/find_bar/find_bar_controller.cc:124:
find_tab_helper->StopFinding(kClearSelectionOnPage);
This fix isn't correct. This breaks the following use-case:

1. Search in tab A.
2. Switch to tab B.
3. Switch to tab A.
4. Find count and highlighting should still be visible in tab A.

[Deepak, 2014-08-25 14:22:42]

https://codereview.chromium.org/498133002/diff/1/chrome/browser/ui/find_bar/f...
File chrome/browser/ui/find_bar/find_bar_controller.cc (right):

https://codereview.chromium.org/498133002/diff/1/chrome/browser/ui/find_bar/f...
chrome/browser/ui/find_bar/find_bar_controller.cc:124:
find_tab_helper->StopFinding(kClearSelectionOnPage);
On 2014/08/25 10:50:41, Finnur wrote:
> This fix isn't correct. This breaks the following use-case:
> 
> 1. Search in tab A.
> 2. Switch to tab B.
> 3. Switch to tab A.
> 4. Find count and highlighting should still be visible in tab A. 

Thanks for review, I will modify my patch, considering this.

[Deepak, 2014-08-26 03:16:54]

On 2014/08/25 14:22:42, deepak.m1 wrote:
>
https://codereview.chromium.org/498133002/diff/1/chrome/browser/ui/find_bar/f...
> File chrome/browser/ui/find_bar/find_bar_controller.cc (right):
> 
>
https://codereview.chromium.org/498133002/diff/1/chrome/browser/ui/find_bar/f...
> chrome/browser/ui/find_bar/find_bar_controller.cc:124:
> find_tab_helper->StopFinding(kClearSelectionOnPage);
> On 2014/08/25 10:50:41, Finnur wrote:
> > This fix isn't correct. This breaks the following use-case:
> > 
> > 1. Search in tab A.
> > 2. Switch to tab B.
> > 3. Switch to tab A.
> > 4. Find count and highlighting should still be visible in tab A. 
> 
> Thanks for review, I will modify my patch, considering this.

@Finnur
Can you suggest how can we distinguish that when we move from Tab A to Tab B and
coming back in the Tab A, That weather we have done reload before moving to Tab
B.
As we have 2 scenario's 
one that you mentioned above.
other is :
1. Search in tab A.reload, and while it is reloading 
2. Switch to tab B.
3. Switch to tab A.
4. highlight's is not their , but count is their.
I checked  FindBarController::ChangeWebContents() , but can not make any
different in our 2 sceneries.
Any part of code I should look at to distinguish these 2 scenerios.

[Finnur, 2014-08-26 10:04:30]

I don't exactly know where the fault lies and I haven't had time to look into
it. I don't think we should be trying to determine whether a reload happened in
a tab and whether we are switching to/away from such a tab. That seems a bit too
hacky and I think the solution lies elsewhere. I'm not sure where, though.

[Deepak, 2014-08-28 06:19:50]

On 2014/08/26 10:04:30, Finnur wrote:
> I don't exactly know where the fault lies and I haven't had time to look into
> it. I don't think we should be trying to determine whether a reload happened
in
> a tab and whether we are switching to/away from such a tab. That seems a bit
too
> hacky and I think the solution lies elsewhere. I'm not sure where, though.

Ok, Finnur I will try to understand code more and will make patch that fix both
issues & will raise patch.
Thanks for time.

[Deepak, 2014-08-28 07:16:14]

I have done changes that take care of scenerio that you have mentione in
previous review.
find_op_aborted_ will get set when reload happen,and when same content comes
while coming back to the previous visited tab then we can easily get info that
weather reload happened in that tab.
Have put check for that.With this all scenerios are working fine.

PTAL.

[Finnur, 2014-08-28 16:57:22]

This is failing some tests (see
FindInPageControllerTest.PrepopulatePreserveLast).
Suggest running that locally to see what the issue is.

[Deepak, 2014-08-29 13:50:14]

On 2014/08/28 16:57:22, Finnur wrote:
> This is failing some tests (see
> FindInPageControllerTest.PrepopulatePreserveLast).
> Suggest running that locally to see what the issue is.

Thanks, I will check this locally.

[Deepak, 2014-09-01 16:02:44]

PTAL.

[Deepak, 2014-09-03 03:31:47]

The CQ bit was checked by deepak.m1@samsung.com

[Deepak, 2014-09-03 03:32:04]

The CQ bit was unchecked by deepak.m1@samsung.com

[Deepak, 2014-09-04 14:12:11]

PTAL

[Finnur, 2014-09-05 10:13:44]

I can't repro any issue from the bug referenced. Maybe continue this discussion
there?

[Deepak, 2014-09-05 12:18:46]

On 2014/09/05 10:13:44, Finnur wrote:
> I can't repro any issue from the bug referenced. Maybe continue this
discussion
> there?

I agree the original issue mentioned issue in not their.
But on reload we should remove the Find bar right!!!

[Finnur, 2014-09-05 12:28:04]

Yes, that's a separate issue, tracked in another CL and another bug. I'm closing
this out then.