This post is for gathering feedback about the experimental editor rework launched in Anki 26.08.
What Changed
At the moment this is mainly an internal code refactoring to make possible to integrate the editor into mobile apps[1] and the focus is on preserving functionality. There are UI improvements planned as part of this project in the future.
How to enable it
You can enable it from Preferences>Experiments or hold shift while opening the Add/Edit/Browse screens to temporarily toggle it on/off.
Known Issues
Add-on compatibility is not guaranteed. Most editor add-ons are not expected to work yet, but feel free to post issues and errors here. If you’re an add-on developer, feedback about what APIs you need in your add-on is appreciated.
Here’s a frustrating bug. The caret jumps to the end after any edits. This seems to happen in the browser, where I do most of my editing, not the add-note or edit-note window (as far as I can tell).
Attached video with keypresses showing, run from source on the main branch with no add-ons and a fresh profile.
I’ve been able to vibecode a fix but didn’t want to just make a PR without going through the proper channels, and without knowing exactly how you want the bug fixed.
It’s a feedback loop: the editor gets told about its own save and reloads the note.
You type, and 600ms later the Svelte editor saves the note through a backend call.
The Python media server fires the “an operation changed something” hook. It sets the initiator to the active top-level window, e.g. the Browser.
Every web view passes that hook on to its JavaScript, except when the initiator is its own parent widget (webview.py:1034). That check can never match the editor: its parent is the form’s fieldsArea widget, not the window.
The editor’s JavaScript sees “note text changed” and calls reloadNote() (NoteEditor.svelte:1280). That re-renders the fields and puts the caret at the end.
The wait between your edit and the jump is the 600ms save delay plus the round trip. The Add window is not affected, because in add mode the editor only reloads when the note type or deck changes. The “Edit current” window (opened from the reviewer) should have the same bug, so please check it too.
[Title: Reversed Text Input When Adding a New Note]
Steps to Reproduce
Enable the New Experimental Note Editor.
Press A to open the Add Note window.
Press Tab to move keyboard focus to the first field.
Type Hello.
Actual Behavior
Two issues occur:
Incorrect focus behavior: When the Add Note window opens, the first field appears to be focused, as indicated by its blue border. However, it does not actually have keyboard focus. Typing immediately after opening the window does not enter any text into the field. Pressing Tab is necessary to give the field actual keyboard focus.
Reversed text input: After pressing Tab and typing Hello, the text appears in reverse as olleH instead of Hello.
In other words, the editor displays a visual focus indicator even though the field does not have actual keyboard focus. Furthermore, once keyboard focus is established, text is entered in reverse order.
Expected Behavior
The first field should automatically receive actual keyboard focus when the Add Note window opens.
Users should be able to start typing immediately without pressing Tab.
The visual focus indicator should accurately reflect the field’s actual keyboard focus.
Text should be entered in the correct order, not in reverse.
Additional Comments
This issue appears to have been present since the introduction of the Experimental Note Editor and has persisted across updates. I was hoping it would be addressed by now, but it is still reproducible.