Support the Modern Comments side track pane in MS Word when not accessing MS Word documents via UIA #12988
Conversation
…en not accessing the document via UIA.
In build 13901+, UIA cannot be turned off. Maybe make the setting ternary as with UIA in consoles and make a config spec upgrade? Edit: never mind, looks like the intention in #12982 is to rollback UIA by default. |
|
To clarify, there is another pr for beta, pr #12989 which reverts UIA in
MS Word by default.
There was originally a strong push to have UIA in MS Word by default for
build 13901 and later due to this modern comments bug. However, as I
have now come up with a work around, that push is no longer valid.
We therefore will be deferring this to at least NVDA 2022.1. However,
that push has allowed us to get a lot of further fixes done, including
support for Math. So, I really do hope that by NVDA 2-22.1 we will be
able to switch completely for some build of MS word. Probably something
more like 14326 or when ever UIA custom patterns is available.
|
| and self.getNearestWindowHandle(element) == oldFocus.windowHandle | ||
| and not self.isUIAWindow(oldFocus.windowHandle) | ||
| ): | ||
| IAccessibleHandler.internalWinEventHandler.winEventLimiter.addEvent( |
There was a problem hiding this comment.
Can't we set focus by calling accSelect here?
There was a problem hiding this comment.
It already does have focus according to Microsoft Word, it is just that it doesn't fire the focus winEvent.
Co-authored-by: Leonard de Ruijter <leonardder@users.noreply.github.com>
| if getattr(element, '_isNetUIEmbeddedInWordDoc', False): | ||
| return True | ||
| windowHandle = self.getNearestWindowHandle(element) | ||
| if winUser.getClassName(windowHandle) != '_WwG': |
There was a problem hiding this comment.
_WwG, _WwN, _WwO are used many times throughout the code base, could you put these in a constant?
The advantage would be a name and docs, hopefully giving insight to someone viewing this later and likely having a hard time reversing this class name to work out what control/window did you specifically care about when writing this code. At least a comment to give an indication for how this magic value is found.
| # But, if focus jumps from one of these controls back to the document (E.g. the user presses escape), | ||
| # we receive no MSAA focus event, only a UIA focus event. | ||
| # As we are not treating the Word doc as UIA, we need to manually fire an MSAA focus event on the document. | ||
| self._emitMSAAFocusForWordDocIfNecessary(sender) |
There was a problem hiding this comment.
I'm uncomfortable with word specific code being in this file. This seems like it should be a very general file?
Not something to deal with now (unless it is easy), but something to think about longer term.
| cacheRequest.AddProperty(UIA.UIA_ClassNamePropertyId) | ||
| cacheRequest.addProperty(UIA.UIA_NativeWindowHandlePropertyId) |
There was a problem hiding this comment.
Why is one AddProperty with a cap 'A' and the other lower 'a'?
feerrenrut
left a comment
There was a problem hiding this comment.
Thanks @michaelDCurran
Link to issue number:
Fixes #12982
Summary of the issue:
In build 13901, MS Word introduced "Modern comments" which allows comment threads (I.e. an initial comment plus replies) and the ability to resolve or reopen threads. The new UI to do this is exposed as a new comments side pane which shows the comments and replies in a treeview. This UI is only exposed via UI Automation.
This UI is supposed to completely replace the older Comments story in a document.
As this new UI is imbedded within the document, it shares the same window handle. If NvDA is using the object model to access the document (I.e. the UIA provider of the document's window is ignored) then NVDA never sees the modern comments UI at all. It seems that MS Word does not ever proxy this to MSAA either.
Also, if MS Word detects that something is trying to access the comments via the object model in the old way (E.g. calls comment.range) then the Modern comments UI is disabled (hidden) and MS Word ends up in a state where querying the range at the selection of the object model is no longer in the comments story, yet the UI is not shown either. This MS Word bug is known to Microsoft however they have no plans or willingness to fix it. Their only recommended solution is to stop using the object model and just use UIA.
Description of how this pull request fixes the issue:
in
UIAHandler.handler.isUIAElement: return true if the element's windowHandle is _WwG but an ancestor of the element has a UIA className of NetUIHWNDElement.I.e. this UIA element is a control of a NetUI container embedded in an MS Word document. E.g. a control in the Modern Comments side track pane.
Also, if there is a UIA focus event for the Word document root, even though we are not classing that window as native UIA, if the previously focused object was a control in a NetUI container embedded in the same Word document, then generate an MSAA focus event for the document, as MS Word will not do this itself.
Note that allowing NVDA to track the focus with UIA for these embedded controls is enough to work around the issue, as this then means that focus never hits the Word document while the Comments side track pane should be focused, thus avoids making object model calls MS Word does not like or expect.
Testing strategy:
This can only be tested in conjunction with PR #12989 as UIA in MS word should not be used by default.
Known issues with pull request:
None known.
Change log entries:
New features
Changes
Bug fixes
For Developers
Code Review Checklist: