I think the problem is that VS Code has started to report some partial accessibility information sometimes even when accessibility is disabled, instead of just returning no element at all.
Unfortunately, if there are more than 15 lines selected in this "partial information" mode, it returns an empty string for the selected text range, as well as empty selection ranges. This breaks "draft submit" because we think the draft is empty.
This throws off our previous logic because we assumed if we had an element, we could trust its selected text property.
Small selection (accessibility off):
{
'AXDescription': 'The editor is not accessible at this time. Press Alt+F1 for options.',
'AXSelectedText': ' actions.user.item_run_in_new_pane_below(f\'cd "{escaped_path}"\')',
'AXSelectedTextMarkerRange': None,
'AXSelectedTextRange': <0-71>,
'AXSelectedTextRanges': [<0-71>],
}
Big (15+ lines) selection (accessibility off):
{
'AXDescription': 'The editor is not accessible at this time. Press Alt+F1 for options.',
'AXSelectedRows': [],
'AXSelectedText': '',
'AXSelectedTextMarkerRange': None,
'AXSelectedTextRange': <0-0>,
'AXSelectedTextRanges': [<0-0>],
}
The proper fix is probably to make it such that if we get empty selected text from any application, we have to assume it's not trustworthy, and fall back to the clipboard implementation. This will mean that using it for legitimately empty selections will be slow, but I don't know of a better way, other than perhaps having a setting, so that properly native applications could be excluded.
Reported by @josharian originally.
I think the problem is that VS Code has started to report some partial accessibility information sometimes even when accessibility is disabled, instead of just returning no element at all.
Unfortunately, if there are more than 15 lines selected in this "partial information" mode, it returns an empty string for the selected text range, as well as empty selection ranges. This breaks "draft submit" because we think the draft is empty.
This throws off our previous logic because we assumed if we had an element, we could trust its selected text property.
Small selection (accessibility off):
Big (15+ lines) selection (accessibility off):
Big selection (accessibility on)
("Accessibility" referring to this setting:)
The proper fix is probably to make it such that if we get empty selected text from any application, we have to assume it's not trustworthy, and fall back to the clipboard implementation. This will mean that using it for legitimately empty selections will be slow, but I don't know of a better way, other than perhaps having a setting, so that properly native applications could be excluded.
Note that the clipboard implementation has a slightly different (but much better) failure case for genuinely empty selections: https://github.com/talonhub/community/issues/1210