native selection in Microsoft Outlook: NVDA reports "native copy"

[Adriani90]

Steps to reproduce:

1. Open an email in MS Outlook
2. Run NVDA and Switch to browse mode
3. Select some text
4. Press ctrl+c

Actual behavior:

NVDA reports the NVDA specific message "native copy".
Users get confused because they might get the impression that the copied content in browse mode is different than the one in focus mode. So this is a regression.

Expected behavior:

NVDA should report the "copy" message retrieved by the Outlook app module in browse mode, as it was before impelemnting native copy and same as it does in focus mode, because the same content is copied both in browse and focus mode.

NVDA logs, crash dumps and other attachments:

n/a

System configuration

NVDA installed/portable/running from source:

installed

NVDA version:

alpha-31113,6a43521f (2024.2.0.31113)

Windows version:

Windows 11 23 H2

Name and version of other software in use when reproducing the issue:

Microsoft 365 MSO (Version 2401 Build 16.0.17231.20236) 64 Bit

Other information about your system:

n/a

Other questions

Does the issue still occur after restarting your computer?

yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

, 2024.1 Beta has the same issue.

If NVDA add-ons are disabled, is your problem still occurring?

yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

yes

[Adriani90]

cc: @michaelDCurran is it not possible to go the same way as for MS Excel? In MS Excel nothing changed when copying things in browse mode. Pressing nvda+shift+f10 in MS Excel just brings the context menu of a cell, while pressing ctrl+c both in browse and focus mode announces the same message.

[CyrilleB79]

Writing here for the current issue as for #16201.

Here is the situation with NVDA 2024.1beta9 when pressing control+C:

• In Word with UIA:
  • BM (browse mode): "Native copy"
  • FM (focus mode): "Copy" (UIA notification)
• In Word legacy:
  • BM: "Native copy" overspoken by "Copy" (UIA notification)
  • FM: "Copy" (UIA notification)
• In Outlook (with UIA or legacy, no matter):
  • BM: "Native copy"
  • FM: Nothing

IMO, hearing "Native copy" is not a good user experience, even in Firefox. Indeed, an indication of the text that was copied (or the number of characters for long text) is a much more relevant information. In Office application, it is still less useful since the copy is always native in any case, as it has always been.

In 2023.3, the situation was as follows:

• Outlook (with UIA or legacy):
  • BM: Copied in clipboard: text
  • FM: nothing
• Word (with UIA or legacy):
  • BM: Copied to clipboard: text
  • FM: "Copy" (UIA notification)

This was much better.

[michaelDCurran]

when pressing control+c in focus mode and or native selection, the reason we never say "copied to clipboard" and optionally the text, is because we cannot guarantee that the app actually copied something, and we cannot be sure what the text was that it copied. All we know is that we sent control+c to the app.
In browse mode we can do it as we are the one actually copying the text to the clipboard.
I have always (and probably always will) be unwilling to have NVDA announce that it copied text to the clipboard, unless we actually know it did.
this part can be debated further at some point, but,

For 2024.1 at least, we need to settle on which experience we want. It seems to me that the only option is:

• pressing control+c in native selection mode should no longer say "native copy". Some people already seemed to not like this message, and it seems to conflict with / interrupt other native messages from the app. We would also remove the filtering from MS Word UIA notifications so that NVDA always announced MS Word's "copy" message all the time.
• If however people do still want to hear "copyed to clipboard {text}" when pressing control+c in MS word browse mode, then we need to no longer treat this as equivalent to native selection mode, and go back to copying plain text ourselves. I don't think this would be great for NVDA 2024.1.

Therefore I propose:

• Removing the "native copy" message all together and just letting the app do what ever it does.
• Keep MS Word browse mode copy's new behaviour of copying rich text, but accept that MS Word will just say "copy" or what ever its UIA notification says. We will not say "copied to clipboard {text}". And I acknowledge that this is a deliberate change in behavior.

If this is okay, I shall open a new PR tomorrow. However, if we cannot come up with a consensus, I will simply leave it in its current state for 2024.1. and it should not block the release.

[CyrilleB79]

@michaelDCurran, I have not the time to double check today.
But it seems to me that the UX is worse after #16151 than before.

To summarize, if you cannot make something consistent and satisfying for Word browse mode before 2024.1, better try to stick to 2023.3 experience regarding Word browse mode.
And if NVDA+shift+F10 does not report the correct message in Word, we may fix this in 2024.2 more cleanly.

[Adriani90]

I have always (and probably always will) be unwilling to have NVDA announce that it copied text to the clipboard, unless we actually know it did.

I agree with this in general. In my view it suffices to hear "copy" in browse mode as well when pressing ctrl+c both in outlook and MS Word. This is what I hear when I copy something in focus mode. In MS Word. There is no difference between copying something in focus mode vs. browse mode so the message should be the same. Or am I wrong?
In MS Excel we hear "copy" both in focus and browse mode when pressing ctrl+c.

we cannot guarantee that the app actually copied something, and we cannot be sure what the text was that it copied. All we know is that we sent control+c to the app.

That's interesting to know, thanks for the info.
In this case a neutral but harmonized term like "copy" is best suited because it does not sugerate that something has been really copied but that's what ctrl+c stands for.

Narator reports this UIA message in focus mode and in its scan mode.

[michaelDCurran]

Users get confused because they might get the impression that the copied content in browse mode is different than the one in focus mode. So this is a regression.

this is not a regression, rather it is a change in behavior. If you feel there is a contradiction with the user guide, please suggest a change to the documentation to make it clearer.

NVDA should report the "copy" message retrieved by the Outlook app module in browse mode, as it was before implementing native copy and same as it does in focus mode, because the same content is copied both in browse and focus mode.

I completely disagree. The change in behaviour is now that it copies like focus mode, thus it should not (nor can it) report the original message about copying in browse mode.

The behaviour will stay as is for 2024.1. But Feel free to suggest clarifications to documentation if necessary.
However, if there is in deed a regression or loss of behaviour (excluding a change in the message) then please state this more clearly.

[CyrilleB79]

@michaelDCurran, why have you closed this issue whereas #16262 is not merged?

[CyrilleB79]

NVDA should report the "copy" message retrieved by the Outlook app module in browse mode, as it was before implementing native copy and same as it does in focus mode, because the same content is copied both in browse and focus mode.

I completely disagree. The change in behaviour is now that it copies like focus mode, thus it should not (nor can it) report the original message about copying in browse mode.

@michaelDCurran that's true for UIA but not for legacy. In 2023.3, in legacy browse mode, NVDA copied the text with its formatting and reported the text being copied. In 2024.1beta12 in legacy browse mode, NVDA copies the formatted text but does not report anything.
Could you clarify if NVDA reported the copied text not knowing if it had actually been copied by the application, or if NVDA was able to know that the copy actually had taken place even in browse mode? If the latter, I'll open an issue for this loss of information.