cryptee / web-client

Cryptee's web client source code for all platforms.
https://crypt.ee
Other
444 stars 22 forks source link

[Feature] Allow "creating" line break via cursor placement #169

Closed ghost closed 1 year ago

ghost commented 1 year ago

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Currently we can only create line breaks by pressing enter. This is particularily annoying when trying to exit a formatting mode which is sometimes even downright impossible.

Let's say I'm editing a code section (with cursor marked):

wow im coding

such hacker|

If I wanted to exit this formatting I would either have to: 1 - have some kind of character after this code that I can use to "line break off of", essentially allowing me to "escape" the formatting. 2 - if this is not present, so there is nothing after the code, I would need to add a linebreak in the code formatting section which extends the formatting by one extra row and the cursor is the only one present in that row:

wow im coding

such hacker

|

If I deselect the code formatting feature via the code icon (when it allows me to do it) it will look like this:

wow im coding

such hacker

|

Now I can do whatever I want with the row because I have successfully escaped it with many unnecessary steps.

Additionally if I have a chart, sometimes it becomes really buggy (#158) and after many Enters I still cannot exit it, and nor can I with an icon, because there is none present as new buggy cells are generated. Sometimes editing get's into this limited mode where certain formatting features aren't shown including code formatting and chart icons.

Describe the solution you'd like A clear and concise description of what you want to happen.

If we could (even double or long) tap in a yet to be created row after the last used row and the editor would spawn a new row with the cursor in it, that would solve these inconveniences.

Additional context Add any other context or screenshots about the feature request here.

johnozbay commented 1 year ago

Hi there πŸ‘‹πŸ»

Thanks a lot for taking the time to file these!

What you're describing sounds like a bug. You should be able to exit code blocks by pressing "return" three times :

https://user-images.githubusercontent.com/611338/185777375-2501a750-40dd-4b3d-b109-df2f27a594e4.mov

The reason why it's three times is because if you're typing a new function, you would want to have one empty line between the two functions. i.e.

firstFunction() {

} // return 1
// return 2
secondFunction() {

}

Give this a try, and if this doesn't work, please let us know the specifics of your browser, os, ad blockers etc the bug report template requires, so we can take a look at what might be causing this.

Thanks! ✌🏻

John

ghost commented 1 year ago

This did solve the code issue, thank you. However the chart and it's exit is still really buggy. Tracking at #158 but here is some additional magic.

https://user-images.githubusercontent.com/94188674/185784158-96512d50-87b4-4e86-9fb9-4c8e553d0a65.mp4

johnozbay commented 1 year ago

Actually! The hint I needed for this is in the screengrab. Seeing your keyboard is in Hungarian somewhat explains this bug.

This is a long running Chrome / Android keyboard bug with some keyboards. The problem does not happen with alternative keyboards, but those do not always use IME composition.

I have a whole thread, you can read all about it here : https://github.com/cryptee/web-client/issues/129#issuecomment-877750792

TLDR;

Turns out keyboards like GBoard etc don't actually update cursor position when you press "return/newline" and only update it when you press the next character. So when you press "return/newline", what happens is that the system moves its virtual cursor to where the newline would be, but doesn't report it to the webpage. πŸ€¦πŸ»β€β™‚οΈ To phrase this differently, predictive/auto-corrective keyboards don't move the cursor on newline characters on Android...

In tables, we block "newline" altogether to make sure it doesn't break the table cells / cause further issues related to this bug, and we use some tricks to detect newlines outside of tables, but evidently something's not working again.

I'm going to investigate what might be causing this β€” BUT 100% confident it's related to the same bug as #129. Let's track this there. Because fixing one will fix the other. (And just to be clear, it's not exactly a 'fix' but more of a 'workaround', since if they keyboards don't send newline, we physically can't know if we should insert a newline / exit or not)

Thanks for the video this was immensely helpful! Team and I will take a look and try to reproduce this!

ghost commented 1 year ago

I'll try checking all these issues, I'm currently away from a desktop.

ghost commented 1 year ago

Actually! The hint I needed for this is in the screengrab. Seeing your keyboard is in Hungarian somewhat explains this bug.

Please note that I have other screenrecordings where the Hungarian keyboard isn't the one selected in #158. Btw I'm using Florisboard.