My CL fixed some potential bugs but reveal other bugs...

Root cause: we sometimes get inconsistent results from FrameSelection::ComputeVisibleSelectionInDOMTree() and FrameSelection::ComputeVisibleSelectionInFlatTree() that, one of them is non-null but the other is null.

In addition, these two operations have side effect - if one gets null, it sets the other to null. This is normally fine, but when we run into the consistency bug above, we run into troubles...

And chrome://extensions page belongs to such buggy case...

Recap:

1. Ctrl+A sets selection as base: HTML@BeforeChildren, extent: HTML@AfterChildren

2. When clicking back in search field, SelectionController checks whether we are clicking inside existing selection to decide whether create a new selection or not, by calling FrameSelection::Contains()

3. FrameSelection::Contains()_stores the visible selection as

const VisibleSelectionInFlatTree& visible_selection = ComputeVisibleSelectionInFlatTree();

The value of |visible_selection| is non-null at its initialization

4. The function then performs a hit test, which somehow calls ComputeVisibleSelectionInDOMTree() inside and got null, which also sets ComputeVisibleSelectionInFlatTree()'s result to null.

5a. Before my patch, |visible_selection| holds a reference to |SelectionEditor|'s stored result of CVSinFT(), which becomes null after the hit test. Hence, after the hit test, FrameSelection::Contains() checks the hit test result against a null selection and returns false.

5b. After my patch, |visible_selection| becomes an independent temporary variable, which remains non-null after the hit test. Then FrameSelection::Contains() checks the hit test result against this non-null selection and returns true, which blocks the caret to be set in the search field.

>#c1, The function then performs a hit test, which somehow calls ComputeVisibleSelectionInDOMTree() inside

Could you put exact location where calling ComputeVSInDOMTree() during hit test?
We should fix that.

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

commit b6f6b01534cbc5525b5d57b9693a1c2053c52f22
Author: Xiaocheng Hu <xiaochengh@chromium.org>
Date: Fri May 25 05:30:38 2018

Make FrameSelection::Contains return false for null VisibleSelection in DOM tree

This is a workaround for  crbug.com/845849 .

In some buggy cases, we get ComputeVisibleSelectionInFlatTree() returning
non-null, but ComputeVisibleSelectionInDOMTree() returning null. This
makes FrameSelection::Contains() return true erroneously.

As we don't have a fix to the inconsistency, this patch adds a
workaround that, we call ComputeVisibleSelectionInDOMTree() first to
set the cached VisibleSelections to null also for flat tree, so that
the following computation does not work on a non-null VS in flat tree
erroneously.

Bug:  845849 
Change-Id: I7255d8224b8b6e29d479dd635e2c4ee99b366fc1
Reviewed-on: https://chromium-review.googlesource.com/1072924
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561775}
[modify] https://crrev.com/b6f6b01534cbc5525b5d57b9693a1c2053c52f22/third_party/blink/renderer/core/editing/frame_selection.cc

Your change meets the bar and is auto-approved for M68. Please go ahead and merge the CL to branch 3440 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

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

commit 4a049d47df6ab86b8fa67acefaba87b570948609
Author: Xiaocheng Hu <xiaochengh@chromium.org>
Date: Mon May 28 18:08:09 2018

Make FrameSelection::Contains return false for null VisibleSelection in DOM tree

This is a workaround for  crbug.com/845849 .

In some buggy cases, we get ComputeVisibleSelectionInFlatTree() returning
non-null, but ComputeVisibleSelectionInDOMTree() returning null. This
makes FrameSelection::Contains() return true erroneously.

As we don't have a fix to the inconsistency, this patch adds a
workaround that, we call ComputeVisibleSelectionInDOMTree() first to
set the cached VisibleSelections to null also for flat tree, so that
the following computation does not work on a non-null VS in flat tree
erroneously.

Bug:  845849 
Change-Id: I7255d8224b8b6e29d479dd635e2c4ee99b366fc1
Reviewed-on: https://chromium-review.googlesource.com/1072924
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#561775}(cherry picked from commit b6f6b01534cbc5525b5d57b9693a1c2053c52f22)
Reviewed-on: https://chromium-review.googlesource.com/1075707
Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#14}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/4a049d47df6ab86b8fa67acefaba87b570948609/third_party/blink/renderer/core/editing/frame_selection.cc

Update : 
Retested above issue in latest Dev build #68.0.3440.7 on Windows(7, 8, 8.1, 10), Mac(10.12.6, 10.13.1, 10.13.5) & Linux 14.04 LTS OS and the issue is fixed. Text caret is seen as expected in 'Search box' for the first instance. Kindly review an attached screen-cast for the reference.

Thank you..!

Deleted: Latest_behaviour.mp4 273 KB

	Latest_behaviour.mp4 273 KB View Download