dear reviewers thanks in advance for your time and patience,
this fixes the bug, see screenshots in the issue.
please let me know if you want me to address anything!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
+pdr@ who reviewed the original CL: https://chromium-review.googlesource.com/c/chromium/src/+/6828942 as they have more context on this class
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Fix selection handles hidden when line-height exceeds input heightDid you check if this works end-to-end? I think the code in ComputeViewportSelectionBound will hide these handles? Or maybe that code won't for some reason?
// Use the full selection edge for visibility testing. The handle should beYou removed the comment about ComputeViewportSelectionBound. Is that still important to keep?
gfx::Rect sample = gfx::BoundingRect(bound.edge_start, bound.edge_end);Can you wrap this in a feature check of some kind (similar to the SelectionHandleWithBottomClippedEnabled code you removed)? We've had issues with regressions in this area, and having a runtime enabled feature will let us revert back to the code before your change in an emergency situation.
If this change is entirely in blink/, a RuntimeEnabledFeature is easiest. If this needs to touch cc code too, cc/base/features.h may be the best.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Fix selection handles hidden when line-height exceeds input heightDid you check if this works end-to-end? I think the code in ComputeViewportSelectionBound will hide these handles? Or maybe that code won't for some reason?
tried with and without patch, see screenshot in issue (https://issues.chromium.org/issues/451833352)
// Use the full selection edge for visibility testing. The handle should beYou removed the comment about ComputeViewportSelectionBound. Is that still important to keep?
sorry restored the ComputeViewportSelectionBound() reference and clarified the intent.
gfx::Rect sample = gfx::BoundingRect(bound.edge_start, bound.edge_end);Can you wrap this in a feature check of some kind (similar to the SelectionHandleWithBottomClippedEnabled code you removed)? We've had issues with regressions in this area, and having a runtime enabled feature will let us revert back to the code before your change in an emergency situation.
If this change is entirely in blink/, a RuntimeEnabledFeature is easiest. If this needs to touch cc code too, cc/base/features.h may be the best.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Fix selection handles hidden when line-height exceeds input height
Use the full selection edge for visibility testing instead of a 1px sample
near edge_end, so handles show when any part of the edge is within the clip.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
sample = gfx::BoundingRect(bound.edge_start, bound.edge_end);This behavior will be inconsistent with the CC side behavior, which will make the visibility of selection handles along composited layer bounds behaves differently. For example, in the composited code path, selections with only the top half visible won't have selection handles. Also when only the top of the selection is visible, the selection handle will have a distance to the visible selection, which looks weird.
I think at least we need to keep the two code paths behave the same, i.e. also implement this behavior in cc.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
sample = gfx::BoundingRect(bound.edge_start, bound.edge_end);This behavior will be inconsistent with the CC side behavior, which will make the visibility of selection handles along composited layer bounds behaves differently. For example, in the composited code path, selections with only the top half visible won't have selection handles. Also when only the top of the selection is visible, the selection handle will have a distance to the visible selection, which looks weird.
I think at least we need to keep the two code paths behave the same, i.e. also implement this behavior in cc.
@wangx...@chromium.org oh, thanks for the explanation, will do a follow up!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
sample = gfx::BoundingRect(bound.edge_start, bound.edge_end);Helmut JanuschkaThis behavior will be inconsistent with the CC side behavior, which will make the visibility of selection handles along composited layer bounds behaves differently. For example, in the composited code path, selections with only the top half visible won't have selection handles. Also when only the top of the selection is visible, the selection handle will have a distance to the visible selection, which looks weird.
I think at least we need to keep the two code paths behave the same, i.e. also implement this behavior in cc.
@wangx...@chromium.org oh, thanks for the explanation, will do a follow up!
follow up: https://chromium-review.googlesource.com/c/chromium/src/+/7614280
test APK's and screenshots are here: https://static.januschka.com/issue-451833352/
return start < end ? -1 : start > end ? 1 : 0;Another method is to change `-1` and `1` here to something like `4` to cover large device scale factors. That would be a simplication of my original idea to plumb device scale factor here. I think this is better than the new behavior with gap between the selection and the selection handle when the bottom of the text is clipped. Is there any chance you could test this method?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |