Bugzilla

(In reply to Ting-Yu Lin [:TYLin] (UTC-7) from comment #19)

> Re comment 16:
> 
> > Ting-Yu, is there ever a situation where selecting an element covering the entire viewport is desirable? If not, adding a guard for this might be an easy way to break the cycle.
> 
> I don't think there's a situation we'd want to select an element that covering the entire viewport.

I mean it's rare in a real webpage that the user is long-tapping to select an element that coverts the entire viewport.

Also, there's a separate issue in the original twitter STR. The user is just single tapping on the image. AccssibleCaret doesn't have any special logic to handle single tapping, it just update the blue caret handles in `AccessibleCaretManager::OnSelectionChanged` callback. So we also need to investigate why a single tapping create a non-collapsed selection range for that image.

(In reply to Ting-Yu Lin [:TYLin] (UTC-7) from comment #19)

> Re comment 16:
> 
> > Ting-Yu, is there ever a situation where selecting an element covering the entire viewport is desirable? If not, adding a guard for this might be an easy way to break the cycle.
> 
> I don't think there's a situation we'd want to select an element that covering the entire viewport. 

I mean it's rare in a real webpage that the user is long-tapping to select an element that coverts the entire viewport. Of course, as dholbert points to me on IRC, "select-all" is a viable action to select such an element like in test case 1 in comment 13.

Also, there's a separate issue in the original twitter STR. The user is just single tapping on the image. AccssibleCaret doesn't have any special logic to handle single tapping, it just update the blue caret handles in `AccessibleCaretManager::OnSelectionChanged` callback. So we also need to investigate why a single tapping create a non-collapsed selection range for that image.