Text editing inside of Transformed.scale

[justinmc]

Fixes bugs in the text selection positioning calculations so that they work even when the field is scaled. In many cases, we were simply translating things around without applying the proper localToGlobal (or vice versa) transform.

Before	After

Partial fix for: #144685
It looks like there are other problems where transforms aren't applied properly. Putting a transform at the root of the application, above MaterialApp, will expose more problems.

Sample code

import 'package:flutter/material.dart';
import 'package:webview_flutter/webview_flutter.dart';

void main() => runApp(const _App());

class _App extends StatelessWidget {
  const _App();

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(home: _Home());
  }
}

class _Home extends StatefulWidget {
  const _Home();

  @override
  State<_Home> createState() => _HomeState();
}

class _HomeState extends State<_Home> {
  final _controller = WebViewController();
  final TextEditingController textEditingController = TextEditingController(
    text: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.',
  );
  final OverlayPortalController overlayPortalController = OverlayPortalController();

  @override
  void initState() {
    super.initState();
    _controller
      ..setJavaScriptMode(JavaScriptMode.unrestricted)
      ..loadRequest(Uri.https('api.flutter.dev'));
  }

  @override
  Widget build(BuildContext context) {
    overlayPortalController.show();
    return Scaffold(
      appBar: AppBar(
        title: const Text('Scaled WebView Tester'),
      ),
      body: Stack(
        children: <Widget>[
          Transform.scale(
            alignment: Alignment.topLeft,
            scale: 0.5,
            child: TextField(
              controller: textEditingController,
              maxLines: null,
            ),
          ),
          OverlayPortal(
            controller: overlayPortalController,
            overlayChildBuilder: (BuildContext context) {
              return Positioned(
                top: 0.0,
                left: 0.0,
                child: SizedBox(
                  height: 1000,
                  width: 1000,
                  child: Stack(
                    children: <Widget>[
                      Positioned(
                        top: 90.0,
                        left: 0.0,
                        child: Container(
                          height: 1.0,
                          width: 1000,
                          color: Colors.blue,
                        ),
                      ),
                      Positioned(
                        top: 102.0,
                        left: 0.0,
                        child: Container(
                          height: 1.0,
                          width: 1000,
                          color: Colors.blue,
                        ),
                      ),
                    ],
                  ),
                ),
              );
            },
          ),
        ],
      ),
    );
  }
}

[LongCatIsLooong]

This class probably indirectly stores a reference to the target Overlay somewhere, so you don't have to find it again?

[justinmc]

I just looked and couldn't find one, only references to the OverlayEntries.

[LongCatIsLooong]

nit: get the transform and apply it to the Rect instead?

[LongCatIsLooong]

also why is it called global if the coordinate system is just the overlay?

[justinmc]

1. TIL MatrixUtils.transformRect.

2. You're right, I'll change the naming to "overlay" instead of "global" and make sure all the calculations are relative to that. This will actually matter if there is a transform above the MaterialApp, so we should get it right.

[LongCatIsLooong]

Consider storing the transform and applying it instead of using localToGlobal.

[justinmc]

See my response to #146019 (comment).

[LongCatIsLooong]

Suggested change

	_endHandleDragPositionToCenterOfLine = centerOfLineGlobal - details.globalPosition.dy;
	_endHandleDragPositionToCenterOfLine = centerOfLineGlobal - details.globalPosition.dy;

[LongCatIsLooong]

This refers to using seslecionEndpoints instead of the pointer event? Then maybe move the comment up?

[justinmc]

I rephrased the comment to be more clear about what it's referring to.

[LongCatIsLooong]

Why do we have to deal with drag position deltas and change coordinate systems back and forth? Can we use the current location to calculate where the handle/magnifier should be?

[justinmc]

The trickiness here is that the handle needs to snap to the scaled lines. The snapping calculations are done in local coordinates and then it's converted back to global coordinates. After reading your comment I played around with some refactoring but ended up just renaming some things to try to make it more clear.

[LongCatIsLooong]

Doesn't getPositionForPoint do the snapping? Why is additional snapping needed?

[justinmc]

Sorry for my bad explanation, it's more subtle than my comment made it seem. Simply maintaining the offset between the contact point and the place in the text it points to is not enough. You can see why by doing this:

1. Get out your phone and find a multiline text field (native or Flutter app).
2. Tap to place the cursor.
3. Drag the cursor slowly down until it jumps to the next line.
4. Immediately drag back up until it jumps to the original line.

Notice that it doesn't jump back immediately. There is no balance point at which the cursor can jump up or down with a slight drag, like there would be if it was simply using an offset. You must drag a full line height for it to change lines in either direction.

I'm adding some details about this in the code comments.

[LongCatIsLooong]

Can you add tests for the RenderEditable changes?

[LongCatIsLooong]

LGTM

[LongCatIsLooong]

Doesn't getPositionForPoint do the snapping? Why is additional snapping needed?