[Bug] Text selection tool tip placement and scrolling at the end of a document

[dhda]

Describe the bug Text selection tool tips are inaccessible at the very top or near the bottom of the document.

To Reproduce Select text at the very top of the document, and notice how the system tool tip is displayed on top of Cryptee's tool tip.

Select text near the bottom of the document, and notice how Cyptee's tool tip is displayed below the keyboard. Basically, text that is far enough away from the bottom that the tool tip will be oriented below the text.

Select text at the very bottom of the document, and notice how Cryptee's tool tip (which is oriented above the text) is covered by the system tool tip (no screenshot of this case).

I think there is another issue at play here, too. It seems like Cryptee tries to move up the document above the keyboard when you're editing text that would be covered up, but it only does it once when you enter cursor mode, which means that any text below that point remains inaccessible (below the keyboard) even if you try to scroll. I'm a big fan of editors that allow scrolling past the end of the document, and a full implementation of that would both be a great feature for Cryptee, and would naturally and elegantly resolve the tool tip weirdness at the bottom of the document. As it is I usually just pad out the bottoms of my documents with a bunch of blank lines to avoid these issues, but it's a bit annoying.

Expected behavior It's possible to use the text selection tool tips even for text at the top or bottom of the document.

Screenshots Very top of the document:

Near the bottom of the document (but not the very bottom):

System Information (please complete the following information):

• Device: iPhone 6s
• OS: iOS 14.4
• Browser: Safari PWA

[johnozbay]

We're looking into this now –  By any chance did disabling the zoomed-mode make things better or worse with the scroll for this?

Looks like what's going on is that our editor's a bit confused about its boundaries on the top/left edges, and we'll have to let it display the tooltip wider and let it overflow to avoid some of these problems.

[johnozbay]

As usual, thank you so much for the screenshots and help! Deeply appreciate it! 🙏🏻

[dhda]

I can reproduce all three cases even in Standard zoom mode. The case of selecting text at the very bottom is slightly improved—the tool tips still overlap, but none of Cryptee’s buttons are entirely covered up.

[johnozbay]

Hi there, Just a quick update.

After a month or two of digging through browser behaviors, specs and documentation, we realized this is actually a Webkit bug. What's more is that iOS Safari offers no way to disable the selection tooltip. For context, see webkit bug still open since 2015.

We've tried a bunch of workarounds / duct-tape solutions :

1 – We've created a test version of the editor that has enough space on the top, so that our selection tooltip for the first line would appear there, (and Safari's would appear below 🤞🏻) but this made Safari show its own tooltip on the top too. 🤦🏻‍♂️

2 – We've created another test editor that has no on the top, and the toolbar is overlapping the text editor, with just the right amount of padding to allow Safari's selection tooltip to live there, but not ours. This seems like it may work (but still has a few issues, i.e. Safari's selection tooltip covers our top-toolbar, where you can create tables / checklists etc for example) so if the first line is selected, we could try to show those toolbar options in our tooltip, in anticipation that Safari's selection tooltip would cover those options)

3 – We're trying to find workarounds to shrink Safari's own selection tooltip. For example, passing in : -webkit-user-modify: read-write-plaintext-only; makes Safari hide the bold/italic etc selections (which is great, because we already have those in our pop-up) etc etc. So we're looking for ways to see if we can get rid of the tooltip altogether, and move the copy/paste etc into our tooltip as well. If we can do this, then we can solve a bunch of problems.

4 – Towards the bottom of a document, text becomes inaccessible / unreachable / un-scroll-able behind the keyboard. This seems like an iOS focus issue. We tried a bunch of things here, but none quite fruitful, because there's no guarantee your keyboard will always be as-tall, (i.e. different languages / regions have different-sized keyboard layouts) + you could detach / split the keyboard and move it around etc, and ever since iOS introduced 'keyboard-splitting' it offers no native way to detect if the keyboard is visible / open / split or not. 🤦🏻‍♂️

There is Visual Viewport API since iOS 13, but again split keyboards / bluetooth keyboards etc all have different keyboard characteristics, heights and functions. So we're still investigating this.

---

Right now the only solution / workaround we could find is to ~flush our iOS devices down the drain~ shrink our editor's editable area height when we detect that the keyboard is open. We then try to calculate your position in the document, and slowly adding / removing padding from the bottom of the document to give enough room for the editor to scroll.

If we add too much, then you'll be able to scroll too far down, and text will be outside of the screen. If we add too little, then text will become inaccessible / un-scroll-able behind the keyboard.

So we're working on this fun math problem now. As soon as we solve this, we'll be able to fix all these layout issues.

Hoping all this makes sense. My apologies on behalf of Apple and our team for the delays in fixing this. In the meantime, we're all open for ideas if you can think of a better solution!

[johnozbay]

We've added a small ios specific fix to make the lower parts of the editor work better ~ give it a try and let me know if we could address that part at least.

we're testing an auto-scrolling as you type fix, and we'll release it next week or so 🤞🏻

[johnozbay]

Hi there! I've got some great news!

There is Visual Viewport API ... we're still investigating this.

It works 🎉 So here's what's changing.

– We're moving all editor tools to follow the keyboard, – The list of tools is now scrollable – We're extending the editor to cover the full height of the screen

Here's how it looks like :

When we made it scrollable, we could actually add more tools, so all your lists, tables etc are in here now :

and finally, if you close the keyboard to scroll, here's how it'll look like :

This is to be able to make changes that doesn't require keyboard focus. (i.e. block / line level changes like, create a checklist / convert a regular line to a checklist / create table / create quotes etc. etc.

This version is live on beta now. Check to make sure your version is c07a20d and please let me know if you run into bugs!

This should fix all the bugs listed in this issue, and if you can confirm that this beta version indeed does fix all the bugs, we're going to release this with the upcoming version. It seems to past all of our existing tests, and we're building more as we speak that involve opening and closing the keyboard 100 times haha

Many thanks for your patience and help with this! Deeply appreciated!

Best,

J

[johnozbay]

The beta version is now 714d8c6, we're releasing a bigger update and removing the sidebar on mobile now to address #99. If you run into any issues related to text selection, please report here, and if you run into issues related to sidebar, would be great if you can report to #99 🎉

[johnozbay]

Hi there! Great news, this is now live! Let me know here if you experience any related issues! Many thanks for your patience, understanding and help with all this ✌🏻