Steps to reproduce:

1. Open examples/widgets/richtext/textedit/textedit.app (compiled in Release mode, specifically linked to release versions of Qt)
2. Turn on VoiceOver (Cmd-F5)
3. Move text cursor one line down (down arrow)

Actual Results:

VoiceOver reads the first line of text – "QTextEdit".

Variation: When linked to Debug versions of Qt (those with the suffix "_debug" in library binary name) instead of to the Release versions (those without a suffix), the app instead crashes on an assert:

ASSERT: "*line == -1 || *offset == -1" in file qcocoaaccessibilityelement.mm, line 56
Abort trap: 6

Expected Results:

VoiceOver would read the second visual line of text – "The QTextEdit widget is an advanced editor that supports formatted rich text. It can be " (visual lines depend on text view width, so yours could end with other words, but principle is the same)

Notes:

I traced the culprit to be 4c8cb32 (which fixed QTBUG-49437). It does not take into account that convertLineOffset function requires exactly one of line == -1 (in order to return the line for the given offset) or offset == -1 (in order to return the offset for the given line), and the code currently passes line == 0 and offset >= 0 for multiline text components. I did not document this requirement when I introduced the function (actually, convertLineOffset even has no doc string), which serves as a reminder that even internal stuff should have some basic documentation .

Other symptom is that after interacting with the text (VO-Shift-down) and trying to move the VO cursor down repeatedly (VO-down), VoiceOver does not do so - the VoiceOver cursor stops moving down after getting to the second line ("The QTextEdit widget is an advanced editor that supports formatted rich text. It can be ").

Interestingly, moving text cursor by characters (left/right) or words (Opt-left/right) produces correct speech output, though braille output continues to display VoiceOver cursor contents (first line, i.e. "QTextEdit").