Mobile: Start edit from top #2025
Conversation
|
IMO there should be a setting so that people can choose. But that's not my decision. Let's see what Laurent thinks of the change. |
|
Also, I think you did not install the pre-commit hook. The linter failed in the build step. https://github.com/laurent22/joplin/blob/master/BUILD.md#building-the-tools |
This hopefully alleviates some of the issue in laurent22#1838. At least for me I don't really need a way to scroll quickly, but rather I usually want to add to the top. This commit makes the mobile experience more consistent both with the desktop experience and internally. In the desktop version notes are shown from the top, not the bottom and on mobile the "view note" view already defaults to showing the top of the note and in my opinion it's somewhat surprising when changing to edit that it suddenly jumps to the end.
daniellandau
force-pushed
the
edit-from-top-on-mobile
branch
from
fc0a7e0
to
b3bcaf2
Compare
|
I indeed did not have the hooks installed, thanks for the pointer. Hopefully fixed now. |
|
Thanks for the pull request, but I'm not sure we should merge it. The way it is now is indeed not great, but with this change it's the same situation - for example if I scroll down to the bottom of a note and click Edit, I'm now back at the top. Ideally, when pressing edit, the cursor should go roughly where we are - for example if we are at 50% scroll, the cursor should go at 50% too. But I guess that's tricky to implement? I'm not keen on an option for this either. |
|
As long as we can get the current scroll position (or more precisely the current top of text in view I guess) in a sensible way from the view, it shouldn't be all that tricky to start from that. |
|
A relative |
|
I think the issue is that there's currently nothing to get the webview scroll position, it would have to be implemented first. |
|
I understand Laurent's concerns, maybe a poll could help decide if merging an imperfect fix makes sense? As is, the combination of broken scrolling with jumping to end of note in edit makes it really hard to use on Android for those who add to notes from the top. But I don't know if those of us adding from the top are the overwhelming majority. |
|
I haven't had time to do anything yet, but it should be relatively to simple to implement a scroll listener inside the web view that posts the current scroll position back to React Native. |
|
I pushed a draft of how it would work with monitoring the scroll position of the web view here: daniellandau@498e234. Unfortunately that doesn't work without updating react-native to 0.60 because of this: facebook/react-native@84a1cac. Updating to react-native 0.60 is something I don't want to include here because at least https://github.com/react-native-community/cli/blob/master/docs/autolinking.md and possible other issues with updating react-native that I don't feel qualified to address. Is an update of react-native in the pipeline? If it's not an immediate priority, maybe this pull request could go in as is based on it still being better than the current situation even if not perfect? |
|
Thanks for looking into it @daniellandau. I indeed plan to upgrade RN as soon as possible, so that's not an issue. Does your implementation work if you press on a link and jump to an anchor from within a note - i.e. is the 'scroll' event triggered in this case? I saw you've added the code to weblib but note that this is shared by the mobile and desktop app. A better place might be in the JS injected in NoteBodyViewer, that way it will be only for mobile. |
|
Closing PR for now. Feel free to ask to reopen if you'd like to continue working on it. |
|
Scroll listeners normally do work when clicking on anchor links, so I don't see why they wouldn't. I'll continue working on this once the update to react-native is done. |
|
I opened another ticket and didn't see this closed one, sorry, my bad. Please re-open and keep open this ticket (and freel free to close #2287) until it's fixed, this is the one major annoyance right now - in concuntion with slow scolling behavior and non-working sroll bar on mobile (Android). This desereves a temp fix until a proper solition (start edit at current view position) is implemented. I've read that the @laurent22 isn't keen on an option, but this would be an easy way to help affected users right now, wouldn't it? And it can be removed easily later on.
Thanks! |
|
Cursor beginning to edit at the bottom of note instead of the top (as shown in view mode) is a real problem as I have a significant amount of info in notes and can't scroll up - and unfortunately makes the app in Android unusable. Any progress on this? |
|
@daniellandau it appears that RN was updated. Is this PR still viable and if so, would you mind bringing eyes back to it? Thanks for all of your work on this project @laurent22 and others! |
|
Yes, I noticed but haven't had time to look at it yet. It should be quite doable now. |
|
Latest changelog of version 2.0.2 in Google Play finally says:
But my notes still starts edit at the end, or I get it wrong and it's different issue? |
|
It turns out that editing starts from top (though not where tapped) with new beta editor, there is switch for it in configuration |
This hopefully alleviates some of the issue in
#1838. At least for me I don't really
need a way to scroll quickly, but rather I usually want to add to the top.
This commit makes the mobile experience more consistent both with the desktop
experience and internally. In the desktop version notes are shown from the top,
not the bottom and on mobile the "view note" view already defaults to showing
the top of the note and in my opinion it's somewhat surprising when changing to
edit that it suddenly jumps to the end.