I thought the Smart Selection reset had not landed yet (https://chromium-review.googlesource.com/c/chromium/src/+/653432/ is still being reviewed). Is this a bug that will be introduced by that CL?

Re#2, yeah flicker will be introduced after that cl get landed, open a new crbug to track the issue separately.

I think that normally we don't land patches that have known bugs. Is it feasible to land the flickering fix before the reset patch? You could use dependent patches to get both CLs reviewed in parallel.

Yeah, that's the plan.

amaralp@, it turns out that there is something wrong in cc.

Because we need to deal with shifting (or maybe other type transforms), cc will convert coordinates to under screen coordinates system, then apply an inverse scale factor back. However, for a static selection, it basically identical to the following code.

float x, scalar;
x = x * scalar * (1 / scalar);

On the other hand, for render side, https://cs.chromium.org/chromium/src/content/renderer/render_widget.cc?l=1957 this is a no-op because IsUseZoomForDSFEnabled() switch is not enabled. So we are not doing any transform, which makes sense because it is dealing static selection rectangle.

If we want to match cc in render or blink, we need to apply x = x * scalar * (1 / scalar);, which is weird to me..

While writing example app for  issue 769974 , we found this issue might be inside of Android framework and not only happening for Smart Selection. Remove the blocking and Lower the priority.