NReilingh commented 3 years ago

Overview

Non-fixed-width text fields do not properly render comma-space or period-space combinations. The space appears to have a width of one pixel, and when seeking back and forth across the combination with the arrow keys, the insertion point moves as though the one-pixel space appears before the punctuation.

Screen Capture demonstrating the issue in the notes field of an item

Steps to Reproduce

Put the insertion point in any non-fixed-width text field (anything except a password field in my testing, i.e. the title, username, or notes field of an item, or the search bar
Type a period or comma followed by a space
Observe character render and selection widths by using the arrow keys and shift-arrow keys to navigate across the two characters and select them individually.

I'm inventing these following terms because I am not a typographer:

Character render width: When adding a character a in front of (to the left of) an existing character b, the number of pixels that the rendered position of character b will shift by is the render width of character a.
Character selection width: the number of pixels that a character advances the insertion point by, or the width of the selection highlight for that character.

Users expect character render width and character selection width to be basically the same, or to have similar qualities, even when ligatures are being used.

Expected Behavior

The punctuation character retains the selection width it had before the space was added, and the space character's render and selection width both begin after the punctuation character's render width.

Actual Behavior

The space character's render and selection width appear to completely overlap the punctuation character's, and the selection width of the punctuation character is now approximately one pixel (the selection highlight for the punctuation character is zero pixels wide).

Context

KeePassXC - Version 2.6.4 Revision: b93fbd1

Qt 5.15.2 Debugging mode is disabled.

Operating system: macOS 11.2 CPU architecture: arm64 Kernel: darwin 20.3.0

Enabled extensions:

Auto-Type
Browser Integration
SSH Agent
KeeShare (only unsigned sharing)
YubiKey
TouchID

Cryptographic libraries:

libgcrypt 1.9.1

Operating System: macOS 11.2.3 MacBook Air (M1, 2020) and Mac mini (2018) Reproduced on both Retina and non-Retina displays en-US localization KeePassXC installed via homebrew cask

NReilingh commented 3 years ago

Rendering behavior also appears to affect text in informational dialog boxes.

droidmonkey commented 3 years ago

We don't do anything with font rendering so it's probably a Qt bug. I can replicate the issue.

droidmonkey commented 3 years ago

@phoerious maybe time to pick a new default font on mac?

felker commented 2 years ago

Has this been reported in Qt?

NReilingh commented 2 years ago

@felker Would love to follow it if so, but I'm not readily able to isolate this kind of behavior at the framework level. If anyone does, I would hope they would track any updates they can share on this issue.

I managed to find the Qt bugtracker and found a few possibly relevant issues:

https://bugreports.qt.io/browse/QTBUG-88495?jql=project%20%3D%20QTBUG%20AND%20component%20%3D%20%22GUI%3A%20Text%20handling%22%20AND%20text%20~%20%22comma%22

One in particular is marked as being specific to Big Sur, affecting Qt 5.15.1, fixed in 5.15.3. I'm not sure what is used by KeePassXC, but I'm suspicious of the issue being limited just to Big Sur.

This post may also be helpful: https://codereview.qt-project.org/c/qt/qtbase/+/322102

felker commented 2 years ago

Text rendering seems improved for me on macOS with the 2.7.3 release. Anyone else?

droidmonkey commented 2 years ago

randomness ....