Mobile: Accessibility: Tab ordering has changed on the edit note screen (3.6 regression)

[mrjo118]

Operating system

Android

Joplin version

3.6.12

Desktop version info

No response

Current behaviour

When using a hardware keyboard to navigate the Joplin UI of the edit note screen in Joplin 3.6, the tab ordering has changed since Joplin 3.5. In Joplin 3.5 or earlier, when the title field is in focus, pressing the tab key moves to the collapse / expand button (if present in the version of Joplin) and then to the note body. In Joplin 3.6, after the collapse / expand button, or after the title field if not present, the next tab item is a button in the markdown toolbar, instead of the note body. This means that the tab order is out of order in terms of the order the fields are displayed on the screen. The quickest way to put the title in focus with the keyboard upon opening the note screen is now to tab backwards rather than forwards.

This is likely due to the the React Native 0.81 upgrade. I can produce this behaviour using the Android app, but it may be an issue on iOS as well. This tab ordering is unchanged on the web app

Expected behaviour

The tab ordering should go to the body field after the note title field. If this is not an issue on iOS, the Android only nextFocusForward component prop may provide a means of forcing tab ordering on the screen.

Logs

No response

[SohamJuneja]

I had a look at the relevant code. The toolbar buttons use Pressable (via IconButton.tsx), which appears to have become included in Android's hardware keyboard tab order after the React Native 0.81 upgrade.

The nextFocusForward approach suggested in the issue should work. The fix would be:
Add nativeID="noteBodyEditor" to the outer View of NoteEditor in NoteEditor.tsx
Add nextFocusForward="noteBodyEditor" to the title TextInput in Note.tsx (Android-only prop, so wrapped in a Platform.OS === 'android' check to avoid affecting iOS)
I'll open a PR with this approach.

[mrjo118]

Platform.OS === 'android'

I don't think that's required, as the property should just be ignored, not cause an error. My point about iOS was that this needs to be tested on iOS to see whether it is an issue there also, or if its Android only.

If it does affect iOS too, then an Android only fix would be no good. Do you have appropriate hardware to spin up the app in iOS simulator, or have an iPhone which you can test the latest prerelease on (with a bluetooth keyboard) to check if it is an issue?

[SohamJuneja]

Unfortunately I don't have access to an iOS device or a Mac to run the iOS simulator, so I'm not able to test it on that side.

[varunkumar-22]

I tested this on the iOS simulator with full keyboard access enabled, and the tab order works correctly: title field to collapse/expand button to note body editor. The markdown toolbar is not reached before the note body. This issue appears to be android only
You can checkout following recordings:

Notes editor focused after title field

Screen.Recording.2026-03-07.at.4.21.55.PM.mov

---

Toolbar focused only after the notes editor

Screen.Recording.2026-03-07.at.4.21.32.PM.mov

[mrjo118]

@varunkumar-22 Thank you for testing this! FYI the title has to overflow the edge of the bar for the collapse / expand title button to appear, but I'm going to assume the focus works correctly for that, as the title > body focus was the main problem.

In conclusion, an Android specific fix is the way to go

[varunkumar-22]

I have worked on fixing this issue and after going through the relevant files, i found that it will be good to fix using kotlin, but i need to clarify that native kotlin change is allowed or not?
If so, ready to raise the PR now!

[mrjo118]

I have worked on fixing this issue and after going through the relevant files, i found that it will be good to fix using kotlin, but i need to clarify that native kotlin change is allowed or not? If so, ready to raise the PR now!

Ideally avoid changing the Kotlin if possible, however if this is a generic fix for focus issues (rather than specific to this screen) and is relatively small, then it would probably be acceptable. But would need to see it to know

[mrjo118]

I tried out some Kotlin fixes which AI suggested, and they just ended up either making 2 carats appear (one in TextInput, one in note body) or making the note editor show a big grey overlay when in focus, and the underlying note body was not actually being focus-able. I couldn't get a working solution using nextFocusForward either, as the TextInput doesn't allow setting nextFocusForward on it directly for some reason

[varunkumar-22]

i observed that regression seems to come from react native 0.81 makiing the pressable components focused by default
i tried handling the problem at the activity level by intercepting the tab key in dispatchkeyevent of mainactivity.kt
it is working, i don't know whether it is okay to do it as there might be other things get effected! i am checking
is it okay to go with this approach??

THE-TESR.webm

[mrjo118]

i observed that regression seems to come from react native 0.81 makiing the pressable components focused by default i tried handling the problem at the activity level by intercepting the tab key in dispatchkeyevent of mainactivity.kt it is working, i don't know whether it is okay to do it as there might be other things get effected! i am checking is it okay to go with this approach??
THE-TESR.webm

Please submit the PR and then reviewers can determine whether it is ok