ankitects
Caps lock acts as dead key on macOS/Qt 6.8.1
This is not reproducible in a simple hello-world PyQt app, so it seems to be something specific about our editing environment or app that is triggering this. More experimentation is required.
Working hello-world:
diff --git a/qt/aqt/__init__.py b/qt/aqt/__init__.py
index eca04b261..cb5aa863b 100644
--- a/qt/aqt/__init__.py
+++ b/qt/aqt/__init__.py
@@ -567,7 +567,39 @@ def write_profile_results() -> None:
profiler.dump_stats(profile)
+
+class MainWindow(QMainWindow):
+ def __init__(self):
+ super().__init__()
+ self.setWindowTitle("Hello, World! - PyQtWebEngine")
+ self.resize(800, 600)
+
+ # Create a QWebEngineView widget
+ self.browser = QWebEngineView()
+
+ # Set the HTML content for the browser
+ html_content = """
+ <!DOCTYPE html>
+ <html>
+ <head>
+ <title>Hello, World!</title>
+ </head>
+ <body>
+ <h1 style="text-align: center; margin-top: 20%;">Hello, World!</h1>
+ <div style="border: 1px solid black;" contenteditable=true>type here</div>
+ </body>
+ </html>
+ """
+ self.browser.setHtml(html_content)
+
+ # Set the browser as the central widget
+ self.setCentralWidget(self.browser)
+
def run() -> None:
+ app = QApplication(sys.argv)
+ window = MainWindow()
+ window.show()
+ sys.exit(app.exec())
print("Preparing to run...")
try:
_run()
Injecting <div style="border: 1px solid black;" contenteditable=true>type here</div> into the deckbrowser HTML also triggers the issue, so it doesn't seem to be connected to our sveltekit/editor environment.
Is this about: https://forums.ankiweb.net/t/anki-25-01-02-beta-rc/54490/49?u=namelessgo ?
The lag after using caps lock is not specific to Anki, so it is a mac issue
Would like to retract this bug report, seems like this is affecting outside of Anki and is most likely an problem on MacOS end (Tested with all video drivers on Anki, but this bug is present on all)
Tested on brave browser, terminal and settings
Also presenting the same bug on mac (forum).
I believe this is, indeed, a mac specific issue, but it didn't happen in other Anki version earlier to 25.07.05, and in other mac apps the problem doesn't happen.
Information from the forum topic:
I am able to reproduce this bug.
Anki Version 25.07.5 (7172b2d2) Python 3.13.5 Qt 6.9.1 Chromium 122 Mac Mini M1, macOS Sequoia 15.5 (24F74) and also 15.6 (24G84)
Steps to Reproduce:
- In Anki, open an Add or Browse window and put cursor in a text input field.
- Press the Caps Lock key to toggle it on.
- Press a letter key.
- Note that no letter appears in the text input field as expected. This is the bug.
- Press a letter key.
- Note that the letter correctly appears in the text input field.
- Press a letter key.
- Note that the letter again correctly appears in the text input field.
- Repeat steps 7-8 to see that all subsequent letters appear correctly.
- Press the Caps Lock key to toggle it off.
- Press the Caps Lock key again to toggle it back on.
- Repeat steps 3-11 to see that the bug is repeatable. Each time Caps Lock is toggled on, the next keypress does not appear in the text input field as expected.
Whenever Caps Lock is toggled on, it seems that the next subsequent keypress is incorrectly consumed and the typed letter does not appear as expected.
I am also able to reproduce the same bug but with a similar but slightly different behavior:
- In Anki, open an Add or Browse window and put cursor in a text input field.
- Press the Caps Lock key to toggle it on.
- Press the Caps Lock key to toggle it off.
- Press a letter key.
- Note that no letter appears in the text input field as expected. This is a bug.
- The remainder of this bug behavior is similar to the original bug. The first keypress seems to be consumed after toggling Caps Lock on and then off.
The bug is either seen or not seen depending on the number of Caps Lock toggles:
Toggling Caps Lock: On → bug On, Off → bug On, Off, On → no bug On, Off, On, Off → no bug On, Off, On, Off, On → bug On, Off, On, Off, On, Off → bug On, Off, On, Off, On, Off, On → no bug etc.
The bug behavior occurs also when using the macOS virtual keyboard (“Show Keyboard Viewer”), using the mouse/cursor to enter keypresses on the on-screen, virtual keyboard. So, the issue is not occuring at the physical keyboard/keypress input level but at some level above.
Three other users who experienced the bug confirmed that the bug no longer occurs after downgrading Anki to:
- "25.02"
- "25.02.7"
- "an earlier Anki version"
