From http://crrev.com/2710883002: Expand FrameSeleciton::isNone() to increase chances of hoisting update layout

We should know when VisibleSelection.isNone() != SelectionInDOMTree.isNone()
for replacing FrameSelection.computeVisibleSelectionInDOMTree().isNone() to
FrameSelection.selectionInDOMTree().isNone()


On 2017/02/23 at 00:14:56, yosin wrote:
> On 2017/02/22 at 23:00:34, tkent wrote:
> > lgtm.
> > 
> > On 2017/02/22 at 17:45:50, xiaochengh wrote:
> > > Is there still any intuitive way to check whether FS is none?
> > 
> > IMO, we should not re-introduce isNone() for VisibleSelection in order to help hoisting.  We may have isNone() for SelectionInDOMTree on FrameSelection, but it might not have many users.
> 
> At first glance, FS::isVisibleNone() is attractive, but it is not.
> Since it does not imply it causes layout updating == slow.
> We think "isXXX()" is cheap and does not cause side-effect, but isVisibleNone() is not.
> 
> On rewriting frameSelection().computeVisibleSelectionInDOMTree().isNone(), we need to think we really need to do so.
> I think most of case we can use selectionInDOMTree().isNone() or we should go toward this route.
> 
> Just change frameSelection().computeVisibleSelectionInDOMTree().isNone() to frameSelection().selectionInDOMTree().isNone() then
> which layout tests are failed.
> 
> I have not had simple sample of when VS.isNone() != SelectionInDOM.isNone(), since visible canonicalization moves to visible position
> when HTML have some visible thing, positions go there.

Sounds like something doesn't work correctly...

What's the crucial difference between a "visibly none" selection (i.e., none after canonicalization) and a "truly none" selection (i.e., already none before canonicalization)? Do many clients care about that?
Reply