Repository: nvaccess/nvda

Issue:
When navigating through a threaded conversation in Teams, keyboard focus moves to emoji menu and NVDA reads "menu
Note: this issue doesn't occur with Narrator or JAWS.

### Steps to reproduce:
In Microsoft Teams, press Ctrl+3 to navigate to the Teams/Channels part of the application
In the list of teams/channels, arrow down to a channel and press Enter
With focus on the "new conversation button" press Shift+Tab
Focus lands in the conversation list - Toggle off browse mode 
Arrow up to a conversation with a reply added to it
Press Enter to interact with the conversation
Arrow down to the reply

### Actual behavior:
<!--
Use "Speak command keys" (NVDA+4) and speech viewer to copy and paste here. 
Use braille viewer to copy and paste here.
You may additionally include an explanation.
-->
New conversation button
shift+tab
Threaded conversation with 1 replies, from John Doe, test, started on Monday, November 7, 2022 12:45:44 PM. 1 replies, 0 new. Last reply by John Doe on Monday, November 7, 2022 12:47:07 PM. Press Enter to drill in to reply and read messages. Press Enter again to drill into a message for other actions.  Use Escape to pop out. Use the down arrow key to focus on the Reply button. Press Enter to start your reply section
enter
Message from John Doe. test. Sent on Monday, November 7, 2022 12:45:44 PM. Press Enter to explore message content, then use Escape to shift focus back to the message.  section
down arrow
Reply from John Doe. menu

### Expected behavior:
In this case, NVDA is reading the sender and "menu", rather than the sender, message, time, etc. NVDA shouldn't read menu at all here.
Reply from John Doe. test 2. Sent on Monday, November 7, 2022 12:47:07 PM. Press Enter to explore message content, then use Escape to shift focus back to the message.  section

### NVDA logs, crash dumps and other attachments:
Speaking [LangChangeCommand ('en_US'), 'New conversation', 'button', CancellableSpeech (still valid)]
IO - inputCore.InputManager.executeGesture (12:48:38.673) - winInputHook (13060):
Input: kb(laptop):shift+tab
IO - speech.speech.speak (12:48:38.683) - MainThread (12472):
Speaking [LangChangeCommand ('en_US'), 'shift+tab']
IO - speech.speech.speak (12:48:39.466) - MainThread (12472):
Speaking [LangChangeCommand ('en_US'), 'Threaded conversation with 1 replies, from Jeremy Curry, test, started on Monday, November 7, 2022 12:45:44 PM. 1 replies, 0 new. Last reply by Jeremy Curry on Monday, November 7, 2022 12:47:07 PM. Press Enter to drill in to reply and read messages. Press Enter again to drill into a message for other actions.\xa0 Use Escape to pop out. Use the down arrow key to focus on the Reply button. Press Enter to start your reply', 'section', CancellableSpeech (still valid)]
IO - inputCore.InputManager.executeGesture (12:48:40.934) - winInputHook (13060):
Input: kb(laptop):enter
IO - speech.speech.speak (12:48:40.961) - MainThread (12472):
Speaking [LangChangeCommand ('en_US'), 'enter']
IO - speech.speech.speak (12:48:41.204) - MainThread (12472):
Speaking [LangChangeCommand ('en_US'), 'Message from Jeremy Curry. test. Sent on Monday, November 7, 2022 12:45:44 PM. Press Enter to explore message content, then use Escape to shift focus back to the message.', 'section', CancellableSpeech (still valid)]
IO - inputCore.InputManager.executeGesture (12:48:41.979) - winInputHook (13060):
Input: kb(laptop):downArrow
IO - speech.speech.speak (12:48:42.006) - MainThread (12472):
Speaking [LangChangeCommand ('en_US'), 'down arrow']
IO - speech.speech.speak (12:48:42.294) - MainThread (12472):
Speaking [LangChangeCommand ('en_US'), 'Reply from Jeremy Curry. test 2. Sent on Monday, November 7, 2022 12:47:07 PM. Press Enter to explore message content, then use Escape to shift focus back to the message.', 'section', CancellableSpeech (still valid)]
IO - speech.speech.speak (12:48:42.800) - MainThread (12472):
Speaking [LangChangeCommand ('en_US'), 'menu', CancellableSpeech (still valid)]
DEBUGWARNING - RPC process 19956 (Teams.exe) (12:48:42.920) - Dummy-6 (17432):
Thread 2024, build\x86_64\vbufBase\storage.cpp, VBufStorage_buffer_t::locateTextFieldNodeAtOffset, 870:
Offset 7434 out of range. Returnning NULL

### System configuration
#### NVDA installed/portable/running from source:
Repros in all cases

#### NVDA version:
2022.3.1

#### Windows version:
22H2 OS Build 22623.885

#### Name and version of other software in use when reproducing the issue:
Microsoft Teams - 
1.5.00.31029 
#### Other information about your system:

### 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.
Repros in 2022.2.1
#### If NVDA add-ons are disabled, is your problem still occurring?

#### Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Microsoft Teams: Menu focused when trying to read a message
### Steps to reproduce:
1. Install most recent Teams
2. Focus an incoming message in a chat or team channel.

### Actual behavior:
NVDA reads the incoming message.

### Expected behavior:
NVDA starts reading the incoming message, but this is suppressed by a menu getting focus. This is the menu that allows you to pick a reaction for a message (e.g. like). A focus triggers this menu. It doesn't strictly gain focus, however NVDA"s handling of the menuStart event redirects focus to it.

### System configuration
#### NVDA installed/portable/running from source:
Installed

#### NVDA version:
alpha-21324

#### Windows version:
Windows 10 20H2

#### Name and version of other software in use when reproducing the issue:
Microsoft Teams 1.3.00.28779
Builds like 1.3.00.26xxx don't suffer from this.

### 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.
Yes

#### If addons are disabled, is your problem still occuring?
Yes

#### Did you try to run the COM registry fixing tool in NVDA menu / tools?
N/a


Discussion:
This is a duplicate of #14238  also filed by @msftedad , however, this issue has clearer steps to reproduce.
I am able to reproduce this issue.
This is not the first time we have seen this behaviour though. It was first filed in issue #11821 and was apparently fixed in pr #11822 , however the fix obviously no longer works. I shall look into this.

Technically:
Every time a message is focused, Chromium is sending an EVENT_MENU_POPUPSTART MSAA winEvent. NVDA is (correctly in my opinion) reporting the appearance of the menu, as this is what would happen if a true context menu appeared. It is difficult for us to differentiate between real ones and this (incorrect) one.
I will follow up with Google and Chromium to better understand the exact situations that cause them to fire an EVENT_MENU_POPUPSTART. But I would also appreciate knowing from Teams, how / why they are creating a (presumably visible) menu every time a message is focused. It would be much better if this did not have an ARIA role of menu, especially if they do not want the AT to perform its default menu behaviour.
I accept the fact that Narrator / Jaws are not affected by this bug, thus why we will look into what we can do / what Google can do. as well. But I would still strongly argue, that this is very bad accessibility UX and that menu should not be conveyed to ATs, unless it is actually active.  
My conversation about this with Google has suggested this may be a bug in Chromium, in that the MENU_POPUPSTART event should only be fired if focus is within the menu already. Google would appreciate if Teams could file a Chromium bug and or contribute a fix to Chromium themselves.
Alternatively, I would recommend that teams does not put a role of menu on that node when a message gets focus, which will also suppress the menu event.
Firefox would fire this event in this case as well. It's worth noting that restricting this event to only fire when the menu has focus would break cases where a menu opens but an item inside the menu isn't focused, as happens with native Windows context menus. Arguably, that's a bad pattern anyway - a menu item or the menu itself should probably be focused - but this happens in the wild on the web; e.g. the Options menu for GitHub comments.
Good morning,

Is there any chance this could be modified for Teams only? I personally would not like it either to start adding exclusions for applications but it is greatly effecting the ability for me to work efficiently. Switching to Narrator all day or trying to read threads on my phone are not practical solutions long term.

Thanks.
Relevant logging:

```
DEBUG - IAccessibleHandler.internalWinEventHandler.winEventCallback (09:52:40.166) - MainThread (15784):
Hook received winEvent: EVENT_OBJECT_SHOW, window 1967980 (Chrome_RenderWidgetHostHWND), objectID OBJID_CLIENT, childID -59951, process 2296 (teams), thread 19832
DEBUG - IAccessibleHandler.internalWinEventHandler.winEventCallback (09:52:40.166) - MainThread (15784):
Adding winEvent to limiter: EVENT_OBJECT_SHOW, window 1967980 (Chrome_RenderWidgetHostHWND), objectID OBJID_CLIENT, childID -59951, process 2296 (teams), thread 19832
DEBUG - IAccessibleHandler.internalWinEventHandler.winEventCallback (09:52:40.166) - MainThread (15784):
Hook received winEvent: EVENT_SYSTEM_MENUPOPUPSTART, window 1967980 (Chrome_RenderWidgetHostHWND), objectID OBJID_CLIENT, childID -59951, process 2296 (teams), thread 19832
DEBUG - IAccessibleHandler.internalWinEventHandler.winEventCallback (09:52:40.166) - MainThread (15784):
Adding winEvent to limiter: EVENT_SYSTEM_MENUPOPUPSTART, window 1967980 (Chrome_RenderWidgetHostHWND), objectID OBJID_CLIENT, childID -59951, process 2296 (teams), thread 19832
...
DEBUG - IAccessibleHandler.orderedWinEventLimiter.OrderedWinEventLimiter.flushEvents (09:52:40.191) - MainThread (15784):
Emitting winEvent EVENT_OBJECT_SHOW, window 1967980 (Chrome_RenderWidgetHostHWND), objectID OBJID_CLIENT, childID -59951, process 2296 (teams), thread 19832
DEBUG - IAccessibleHandler.orderedWinEventLimiter.OrderedWinEventLimiter.flushEvents (09:52:40.191) - MainThread (15784):
Emitting winEvent EVENT_SYSTEM_MENUPOPUPSTART, window 1967980 (Chrome_RenderWidgetHostHWND), objectID OBJID_CLIENT, childID -59951, process 2296 (teams), thread 19832
...
DEBUG - IAccessibleHandler.processMenuStartWinEvent (09:52:40.192) - MainThread (15784):
Processing menuStart winEvent: window 1967980 (Chrome_RenderWidgetHostHWND), objectID OBJID_CLIENT, childID -59951, process 2296 (teams), validFocus False
DEBUG - IAccessibleHandler.winEventToNVDAEvent (09:52:40.192) - MainThread (15784):
Creating NVDA event from winEvent: EVENT_SYSTEM_MENUPOPUPSTART, window 1967980 (Chrome_RenderWidgetHostHWND), objectID OBJID_CLIENT, childID -59951, process 2296 (teams), use cache True
DEBUG - IAccessibleHandler.winEventToNVDAEvent (09:52:40.192) - MainThread (15784):
winEvent mapped to NVDA event: menuStart
DEBUG - IAccessibleHandler.winEventToNVDAEvent (09:52:40.197) - MainThread (15784):
Successfully created NVDA event menuStart for <NVDAObjects.IAccessible.ia2Web.Ia2Web object at 0x06458E30> from winEvent EVENT_SYSTEM_MENUPOPUPSTART, window 1967980 (Chrome_RenderWidgetHostHWND), objectID OBJID_CLIENT, childID -59951, process 2296 (teams)
IO - speech.speak (09:52:40.237) - MainThread (15784):
Speaking ['menu', CancellableSpeech (still valid)]
```
Just tested with JAWS, also no issues there. Marking this P2.
@leonardder I just downloaded the latest NVDA (2020.4) and this problem is still there.

It's fixed for the message list, but if you @mention someone and then perform a "say line," NVDA reports "blank." It also continues to remain silent when you press Backspace. The only way to fix it is as before: press Tab to get to the "Send" button, then Shift+Tab to get back to the edit field to continue typing your message.

I've also noticed the ghost menu popping back up when in a call and someone does a screen share. NVDA will announce "menu" and you have to press Tab to get it to focus again on whatever control you were on (like the unmute button.)

So, this issue is not resolved.
I'm afraid for this, either Teams has to fix this properly or we'll have to dive into the core of NVDA with regard to menu popup start events, see https://github.com/nvaccess/nvda/pull/11822#issuecomment-727654478
It's undoable to fix this on a case by case basis as no doubt there'll be a new version of Teams just after a release of NVDA that introduces another incarnation of this issue.
Facing this issue again after the new update of teams!
This is still exist.

Resolving patch:
diff --git a/source/appModules/teams.py b/source/appModules/teams.py
--- a/source/appModules/teams.py
+++ b/source/appModules/teams.py
@@ -17,11 +17,22 @@ class PopOverMenu(Ia2Web):
 class AppModule(appModuleHandler.AppModule):
 
 	def chooseNVDAObjectOverlayClasses(self, obj, clsList):
+		# #11821, #14355
+		# Teams will sometimes create an element with an ARIA role of menu
+		# at the same time another element gets focus,
+		# E.g. an emoji menu appears every time a conversation message is focused.
+		# Web frameworks such as Chromium will tend to fire a menu_popupStart event
+		# when a node with a role of menu is added to the DOM.
+		# NVDA's default behaviour for handling menu_popupStart is to set NVDA's focus to the menu
+		# and cancel speech.
+		# We should deliberately suppress this in Teams however,
+		# Otherwise the focused message cannot be read.
+		# Previously this was limited to message menus, however
+		# As Teams keeps changing the layout,
+		# and all menus in Teams do set focus to their first item when truly focused,
+		# It is safer just to ignore all menu popupStart events within Teams content for now.
 		if (
 			Ia2Web in clsList
 			and obj.IA2Attributes.get("xml-roles") == "menu"
-			and obj.parent
-			and obj.parent.parent
-			and "message-actions-popover-container" in obj.parent.parent.IA2Attributes.get("class", "")
 		):
 			clsList.insert(0, PopOverMenu)


Test patch: