Selftext selection

[AbsurdlySuspicious]

No description provided.

[AbsurdlySuspicious]

It's also somewhat problematic to provide affected thread links for scrolling bug since it seems to be pretty much poorly reproducible. I have some links saved, but they works ok now. I'm not really sure now is this the same bug as the one happening on selftext selection attempts

[AbsurdlySuspicious]

Also selftext view scrolls to its beginning when clicked. I haven't yet checked where even this handler is, but it's probably conflicts with selection too

[tunous-bot]

Test version of Dank has been automatically built from this pull request.
Click here to download it.

[saket]

vote count is rendered using spans to the same textview where the title is, which means that 'select all' selects the vote count too

You could identify the selectable title by reading spans:

val voteSpan = title.getSpans(0, title.length, ForegroundSpan::class.java).first()
val selectableTitle = title.substring(voteSpan.start, title.length)

Obviously this can fail in the future because it assumes there's only one ForegroundSpan and it's used for rendering the vote count, so maybe you should make use of a unique span in SubredditUiConstructor when constructing the title:

Truss titleBuilder = new Truss();
+titleBuilder.pushSpan(new VoteCountSpan())
titleBuilder.pushSpan(new ForegroundColorSpan(ContextCompat.getColor(c, Themes.voteColor(voteDirection))));
titleBuilder.append(Strings.abbreviateScore(submissionScore));
titleBuilder.popSpan();
+titleBuilder.popSpan();
titleBuilder.append("  ");
titleBuilder.append(Html.fromHtml(submission.getTitle()));

val voteSpan = title.getSpans(0, title.length, VoteCountSpan::class.java).first()
val selectableTitle = title.substring(voteSpan.start, title.length)

[AbsurdlySuspicious]

The problem is rather that selection within single TextView can't be limited to some range in an obvious way, so user can freely select anything in it:

I think this is somewhat possible but probably will be extremely buggy. Like listening to touch events or override onSelectionChange and reset the selection or something like that. Splitting this textview in two would be easier and more smooth than this

[saket]

You can't have multiline titles with two TextViews that wrap around the vote count (without a lot of pain). I wouldn't have used a span otherwise. What do you think of listening to copy actions and replacing the clipboard content with text that doesn't include the vote? See `TextView#setCustomSelectionActionModeCallback()`.

…

On Wed, Apr 29, 2020, 5:43 PM AbsurdlySuspicious ***@***.***> wrote: The problem is rather that selection within single TextView can't be limited to some range in an obvious way, so user can freely select anything in it: [image: Screenshot_20200430-003036_1] <https://user-images.githubusercontent.com/46577212/80649442-aeb59380-8a7a-11ea-999b-e8541d8a48a7.jpg> I think this is somewhat possible but probably will be extremely buggy. Like listening to touch events or override onSelectionChange and reset the selection or something like that. Splitting this textview in two would be easier and more smooth than this — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#178 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASG5YEMRMIFQECKQL6TVRDRPCNRFANCNFSM4MTEZFZQ> .

[AbsurdlySuspicious]

I've got some nice results. Check this out: #182
I will keep this one as selftext selection PR

[AbsurdlySuspicious]

I've got this to work normally with this workaround in second commit. Any selectable TextView that gains focus causes RecyclerView to scroll in it's direction. Automatic scroll on tap isn't really harmful but focus gained due to selection causes RV to scroll pretty much randomly and completely messes up selection if TextView doesn't fit on screen. You can see example of this on second gif in #177.

Anyway, long selftexts and comments can be selected without any problems now. Scrolls on reply and comment collapsing both still works and aren't affected by this fix.

[AbsurdlySuspicious]

I haven't actually tested this since I've got no working OTG cable. Arrow navigation aside, two methods below can be effectively replaced by just return false

[Tunous]

Do you think that this is something we should worry about? I've actually never used arrow navigation myself so have no idea how that would affect it.

[AbsurdlySuspicious]

Well, keyboards and stuff. Dawn already uses some rather heavy UI mods so I wouldn't be surprised if it's already broken. Then I just cover these methods with false?

[Tunous]

Let’s keep it. Seems good enough as is for me.

[Tunous]

Please add change-log entry.

[AbsurdlySuspicious]

sorry, forgot that