-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] - Allow vertical scrolling of a multi-line SuperTextField when its text overflows (Resolves #2140 and #1795) #2139
Conversation
@@ -423,7 +423,7 @@ class _TextScrollViewState extends State<TextScrollView> | |||
child: SingleChildScrollView( | |||
key: _textFieldViewportKey, | |||
controller: _scrollController, | |||
physics: const NeverScrollableScrollPhysics(), | |||
physics: isMultiline ? null : const NeverScrollableScrollPhysics(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Passing null
for scroll physics let's the platform dictate the appropriate scroll physics.
Also as far as I could tell this change only applies to mobile SuperTextFields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also as far as I could text this change only applies to mobile SuperTextFields.
Can you mention what that's based on? Without opening the source code I can't tell. Is there a mobile platform check somewhere in this code, or a related place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a code comment that explains why this ternary is here, and can you also add a breadcrumb in that comment for where a developer should look to find scrolling behavior in the case of a single-line text field (for which we disable the physics)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CillianMyles I wanted to make sure you saw the above comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment added + updated! ✅
super_editor/test/super_textfield/super_textfield_gesture_scrolling_test.dart
Outdated
Show resolved
Hide resolved
I checked usages of Did you check what happens with auto-scrolling when dragging selection handles, dragging the caret, etc? Wrapped around the I assume there was a reason that I disabled the standard scroll physics. I'd like to find what that was and then ensure we didn't break those requirements with this change. If this does break those requirements, then we might need to find another way to accomplish this. |
Also, let's move this out of draft mode, and can you also check the failing tests in CI? |
f987f50
to
11f3649
Compare
@matthew-carroll - the tests I added for mobile and desktop are now passing. These tests check to see that multi-line SuperText fields can scroll up and down when the text overflows. I'm not sure if I'll be able to help figure out the reason scroll physics were originally disabled. And in terms of checking the existing functionality with selection handle, magnifiers, scrolling etc.: all existing tests pass, which I hope cover the rules in more detail than I can manually test. In any case I did some manual checks - see: CleanShot.2024-07-17.at.16.54.22.mp4Let me know if there is more you would like me to manually test, or if I should write any more tests. I also now have some golden failures. I tried to update the goldens locally but it ended up with way too many unrelated files changed. Is there something I'm missing with regard to updating the goldens? I am running latest Flutter main:
|
11f3649
to
ea96050
Compare
super_editor/test_goldens/super_textfield/super_textfield_toolbar_test.dart
Outdated
Show resolved
Hide resolved
@matthew-carroll all tests (including new tests & goldens) are now passing. Not sure what to do about the Netlify/deploymant job failures. It seems to be in the middle of setting up Flutter, then switches to I don't think anything I did should affect these jobs? |
@matthew-carroll I think we should fix the goldens: merge either (#2183) or (#2184), and then I will rebase this PR. I see that option 1 works and 2 does not, and also the Netlify jobs didn't fail in option 1 so probably will succeed here after I rebase this PR. Please let me know how we should proceed. |
2a19189
to
a2cf922
Compare
@matthew-carroll this one has been rebased and tests are passing, and ready for another look! |
@CillianMyles do you know if those demo site failures are new to this PR vs broken in general? I don't think I saw those failing in other PRs... |
@matthew-carroll over the past few days/weeks working on a few PRs, I have noticed these fail sometimes. I can't remember in which PRs and it's a bit hard to track down older runs due to rebasing. To be honest thought I can't think why the code changes in this PR could have any affect on these demo site failures. Not sure if it's any use, but now come to think of it, something I do remember when I created the option 1 and option 2 PRs at virtually the same time, the PR checks were actually running at the same time on both, and I noted that the demo site jobs failed on one PR and not the other. Not sure if it could be anything to do with concurrent jobs. Aside from that, I don't have any ideas unfortunately. |
super_editor/test/super_textfield/super_textfield_gesture_scrolling_test.dart
Outdated
Show resolved
Hide resolved
} | ||
|
||
// Ensure the text field has not yet scrolled. | ||
expect(getTextBottom(), lessThan(getViewportBottom())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this how we verify scroll offsets in other tests? I don't remember, but I would assume that we'd access a scroll controller value. Perhaps we even have some test tools for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In different tests in this file, we use both this method, and the SuperTextFieldInspector.findScrollOffset()
method:
https://github.com/superlistapp/super_editor/blob/main/super_editor/test/super_textfield/super_textfield_inspector.dart#L157-L191
I tried the SuperTextFieldInspector.findScrollOffset()
method, but found it did not seem to have the correct value after scrolling back up (0), even though I visually validated the scroll by taking some golden images.
During some debugging, I found the values of the scroll controller, and the values of TextScrollController.scrollOffset
to be off, even though you would expect them to be the same.
When I saw the following comment, it made me think that it would be easier to compare the top and bottom values, since this method is used already in this file, and as I did not really know how to debug this any further.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you file an issue about the inspector method returning the wrong results, and include repro steps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I can do that. It would be easier after landing this PR, as I could modify the tests I've added to use this SuperTextFieldInspector.findScrollOffset()
and show that it produces incorrect results. Would that work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@matthew-carroll as promised: #2256
super_editor/test/super_textfield/super_textfield_gesture_scrolling_test.dart
Outdated
Show resolved
Hide resolved
await tester.pumpAndSettle(); | ||
|
||
// Ensure the text field has scrolled back to the top. | ||
expect(getTextBottom(), lessThan(getViewportBottom())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is lessThan
a sufficient check? One if we only scrolled up 1px....wouldn't this still pass?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct, when changing to scroll only 1 pixel, the test still passes (incorrectly).
I switched approaches to always validate that either the tops or bottoms are aligned (now the test fails when scrolling by only 1 pixel).
ab37160
to
8de952e
Compare
@matthew-carroll I rebased and addressed all your points. Looking forward to your feedback! |
@@ -423,6 +423,8 @@ class _TextScrollViewState extends State<TextScrollView> | |||
child: SingleChildScrollView( | |||
key: _textFieldViewportKey, | |||
controller: _scrollController, | |||
// Passing null for scroll physics for multiline text fields will | |||
// apply an appropriate physics for the underlying host platform. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The operative details we need to capture in this comment is why there's a difference, i.e., why we sometimes disable physics vs sometimes we want the underlying standard physics. Please see the request in my original comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated ✅
chore: fix desktop test
… equals() -> moreOrLessEquals()
6d517dd
to
bd67a68
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@angelosilvestre can you cherry pick this? |
No description provided.