Enable full text selection

[finallyblueskies]

This pull request fixes text selection #22 by adding a button in the chat interface. You can see it here:

https://github.com/psugihara/FreeChat/assets/14274086/8b9d4727-62ab-4f55-9bb7-0de7700c360e

This allows users to select text more easily by removing Markdown rendering.

It makes sense to upgrade this feature to an "Edit message" capability.

Reasoning

Despite my efforts, I couldn't implement full text selection without disabling markdown. This pull request details my struggles, primarily focused on using WKWebView to display messages. Long story short:

• WKWebView isn't suitable because it requires one resource intensive webview per message or complex management for displaying an entire conversation in a webview, which complicates API and style integration between Swift and HTML.
• Native solutions don't work well because they can't handle selection across different views, and complex elements like tables, code blocks, and images can't be effectively managed with NSAttributedString.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
free-chat	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 18, 2024 3:16am

[psugihara]

All makes sense, thanks for all the research here. I agree with the conclusion that it's not worth it to render the whole scrollview with webviews even though that would offer the best text selection. It's weird that browser style text selection is so hard to achieve with SwiftUI but that seems to be the case.

I like this solution from the video but I wonder if it should go in the "..." menu. I'll play with it more tomorrow and have a think.

[psugihara]

Another quick thought. I wonder if there's a hybrid solution where each message renders its own wkwebview for the content (but not the buttons etc). You wouldn't be able to select across messages, but you wouldn't have to toggle on/off to achieve message within the selection and you'd get the richer markdown features you mention.

[finallyblueskies]

Another quick thought. I wonder if there's a hybrid solution where each message renders its own wkwebview for the content (but not the buttons etc). You wouldn't be able to select across messages, but you wouldn't have to toggle on/off to achieve message within the selection and you'd get the richer markdown features you mention.

I tried this and faced hurdles:

• Flashes of unstyled content as view dimensions had to be calculated by the webview
• Resource constraints - rendering more than a few messages each with in its own WKWebView instance started throwing me these errors:

0x1280b3960 - ProcessAssertion::acquireSync Failed to acquire RBS assertion 'WebProcess NearSuspended Assertion' for process with PID=76447, error: Error Domain=RBSAssertionErrorDomain Code=2 "Specified target process does not exist" UserInfo={NSLocalizedFailureReason=Specified target process does not exist}

Error acquiring assertion: <Error Domain=RBSAssertionErrorDomain Code=2 "Specified target process does not exist" UserInfo={NSLocalizedFailureReason=Specified target process does not exist}>

0x1280b39c0 - ProcessAssertion::acquireSync Failed to acquire RBS assertion 'XPCConnectionTerminationWatchdog' for process with PID=76446, error: Error Domain=RBSAssertionErrorDomain Code=2 "Specified target process does not exist" UserInfo={NSLocalizedFailureReason=Specified target process does not exist}

....

These errors suggest that the processes for the WKWebViews were terminated or went missing because the system couldn't allocate the needed resources. No idea if this is workable, from what I've read WKWebViews are pretty resource intensive.

You can try a functional version of the hybrid approach you mention on this commit.