nvaccess
In web browsers, do not eat control+c when no selection is detected (#9833)
Link to issue number:
Fixes #9833
Summary of the issue:
In web browsers, a selection made using a pointing device is not copied to clipboard when pressing control+c
Description of how this pull request fixes the issue:
Send back the gesture if it is either control+c or control+insert. I guess this avoids issues if the script has been assigned alternative gestures, such as a braille one.
Testing performed:
Successfully tested in latest Firefox and Chrome.
Known issues with pull request:
Could other CursorManager uses be badly affected?
Change log entry:
Section: Bug Fixes In web browsers, NVDA no longer blocks control+C from copying text selected with the mouse.
@JulienCochuyt: Could you please add a changelog entry to the PR description, but without "eating something". Because maybe the end user will get hungry after reading this changelog entry. 😉 Thanks.
@JulienCochuyt: Could you please add a changelog entry to the PR description, but without "eating something". Because maybe the end user will get hungry after reading this changelog entry. 😉 Thanks.
Done. Feel free to propose a better way of phrasing the entry.
@JulienCochuyt In the issue referenced above you wrote;
If no selection is detected, send control+C to the application and check whether clipboard content has changed before reporting either "No selection" or "Copied to clipboard". This approach might still give false negatives if the text are identical or lead to hassle with lengthy clipboard contents or contents other than text.
Have you tested this approach? For users especially beginners reporting 'no selection' when copying was actually successful would be very confusing.
@JulienCochuyt In the issue referenced above you wrote;
If no selection is detected, send control+C to the application and check whether clipboard content has changed before reporting either "No selection" or "Copied to clipboard". This approach might still give false negatives if the text are identical or lead to hassle with lengthy clipboard contents or contents other than text.
Have you tested this approach? For users especially beginners reporting 'no selection' when copying was actually successful would be very confusing.
No, due to the mentioned potential hassles. My preferred behavior would be to suppress the "No selection" message altogether, if others agree. The change proposed here is only the least intrusive I could find that fixes the issue.
- More importantly, ctrl+c is eaten by cursor managers on purpose. Peopel are currently expected to pass ctrl+c through to the application.
I hardly understand why the UX is thus changed when using a CursorManager, while the end user should not care about the underlying implementation. This is almost off topic, but I'd be rather interested if you could kindly find the time to explain how that choice was made in the first place.
I've done some quick testing with the keyboard, and I'm pretty sure this alternative will work, at least for Firefox:
- If there is no selection within the cursor manager, create a textInfo for
treeInterceptor.rootNVDAObject- If this selection is not collapsed, then there is some selection in the document that has been made visually.
- In this case, report something interesting.
This is an interesting approach.
Successfully tested with Firefox and Chrome.
Strangely enough (at least to me), the TextInfo retrieved that way does not contain the selection, but rather "\ufffc\ufffc\ufffc\ufffc\ufffc\ufffc\ufffc" and has offsets (2, 3) if there is a selection, (3, 3) otherwise.
@leonardder: Would you have some time to please review the last changes on this PR? The issue was raised once again in #10295.
Strangely enough (at least to me), the
TextInforetrieved that way does not contain the selection, but rather "\ufffc\ufffc\ufffc\ufffc\ufffc\ufffc\ufffc" and has offsets (2, 3) if there is a selection, (3, 3) otherwise.
It would be required to make a Mozilla Compound TextInfo to get the text in the selection, I think.
Strangely enough (at least to me), the
TextInforetrieved that way does not contain the selection, but rather "\ufffc\ufffc\ufffc\ufffc\ufffc\ufffc\ufffc" and has offsets (2, 3) if there is a selection, (3, 3) otherwise.It would be required to make a Mozilla Compound TextInfo to get the text in the selection, I think.
I'm not yet aware of the use of these. Wouldn't this mean to move the fix from CursorManager to some Mozilla-specific class while all browsers are affected? Or is there a mean to create a CompboundTextInfo in a generic way?
Something like this:
from NVDAObjects.IAccessible.ia2TextMozilla import MozillaCompoundTextInfo
info = MozillaCompoundTextInfo(self.rootNVDAObject, textInfos.POSITION_SELECTION)
Note that CompoundTextInfo is very performance heavy
Something like this:
from NVDAObjects.IAccessible.ia2TextMozilla import MozillaCompoundTextInfo info = MozillaCompoundTextInfo(self.rootNVDAObject, textInfos.POSITION_SELECTION)Note that CompoundTextInfo is very performance heavy
Thanks.
But I guess this, if confirmed, would not fit in the generic CursorManager and thus solve the issue only for Mozilla-based browsers… ?
I think either Mozilla or Chromium based. The Mozilla name is a bit misleading here, probably because Firefox came first with their IA2 implementation. For IE, I Wouldn't bother that much, personally.
I think either Mozilla or Chromium based. The Mozilla name is a bit misleading here, probably because Firefox came first with their IA2 implementation. For IE, I Wouldn't bother that much, personally.
Re IE, note that browsable messages are IE-based.
Still, I'll try to test moving the fix to virtualBuffers.Gecko_ia2 and use a Mozilla.CompboundTextInfo there.
I guess we should be able to find out whether there is a visual selection in IE as well.
It seems like momentum was lost on this PR. It looks like there are still a number of outstanding questions here. I'd like to be able to progress this PR, I think it is one of the true thorns for low-vision users or A11Y testers in the default configuration.
this will help a lot low vision users. If NVDA isn't able to tell wheather copy was successful, NVDA could say: Maybe visual selection copied, please check success.
We definitely still get asked about this often. It would be great to have a resolution.
Apologies for ignoring this pr for so many years! However, after considering this further, I believe that this may cause confusion or unexpected behavior for users, so I am unwilling to take this at the moment.
- The blind user is currently unaware if a real non-browseMode selection has been made.
- There are workarounds for the vision impaired / sighted user when selecting with a pointing device: right click and copy, or pass key through and control+c. If in the future we better support the underlying selection (See the new IAccessibleTextSelectionContainer in IAccessible2), then perhaps we can consider this, but only if the underlying selection is somehow exposed to the blind user.
