Use UIA to access MS Word documents by default for MS Office build 16.0.13901 and above #12770
Conversation
….0.13901 and higher.
See test results for failed build of commit 2aec36eb2f |
|
Very exciting! So UIA by default in Word doesn't depend on the new UIA remote operations API in Win 11 (i.e. the current m365 relaese build is good enough for usage by default)? |
|
It doesn't depend on remote operations. But, I think it should check for
a minimum of Windows 10. Thanks for reminding me :)
|
source/_UIAHandler.py
Outdated
| # Disabling is only useful if we can inject in-process (and use our older code) | ||
| and canUseOlderInProcessApproach | ||
| # Allow the user to explicitly force UIA support for MS Word documents | ||
| # Allow the user to explicitly force UIA support on or off for MS Word documents |
There was a problem hiding this comment.
This comment seems misleading: is it possible to explicitly disable UIA support in instances where it would be used by default?
…nything before Windows 10. Also clarify a comment.
|
There are several people I know - either in person or from various discussion lists, who have enabled UIA in Word, tried to work with it for a time and yet decided to return to the Object Model approach. This is anecdotal but most or even all complaints were caused by either #9465 (Selective event registration improves this but apparently it is still not at the level of usability these users expects) or #10610 (the issue is about al HTML applications but see this quote for an example:
I'm not suggesting this PR should be blocked on these but it would be really appreciated if these two issues could be prioritized - they are annoying enough for some that they decided Object Model performance hit is preferable to them and after this PR they would not have a choice any longer. |
|
According to #9465, The MS Word version tested was 1145. We are
switching to UIA by default only for 13901 and later.
I am not personally able to reproduce the lag mentioned, thus I am
hoping that this was fixed in MS Word before then. However, switching
UIA on by default for recent MS Word versions, at least in Alpha, will
hopefully cause users to provide more up to date feedback, and at that
stage we can try and address these things if they are still a problem.
As for #10610, this is a bug that we can fix in NVDA which I will look
into shortly.
Also note that due to some things out of our control, we * must * stop
relying on the object model as of 13901 and instead exclusively use UI
automation going forward. Any remaining bugs in Word's UIA
implementation at that point must be followed up with Microsoft. It is
my understanding that they will prioritize them so that ATs can switch.
|
…(major, minor, build) comparison.
|
Hi! |
|
Yes, as 14326 is more recent than 13901.
|
|
I was wondering why you had not transformed the option in a ternary one as other ones in the advanced panel with the following choices:
By keeping the checkbox, you disallow the third choice. I guess your following comment explains the third choice:
@michaelDCurran could you confirm this? Or indicate clearly another reason why you did not allow to disable UIA in your implementation (iif any)? Thanks. |
|
I don't see any reason to change the option, as we now have no choice
but to stop using the object model in build 13901 and above. thus that
option will eventually become redundant.
|
|
Also issue #11430 will affect many more people (I can still repro on Outlook 16.0.14326.20222). |
|
Issue #12808 applies to UIA word, but seems to also affect the object model (at least on my system). |
|
Issues #9611 and #11430 have now been addressed in separate prs. Again just noting here that MS Word build 16.0.13901 is the first build where a significant bug has been introduced to the Office object model which Microsoft is unwilling to fix. They are requesting NVDA to switch to UI Automation. |
Just for reference, where is it documented? Thanks. |
Fixes #12899 Fix-up of #12908 Relates to #12770 Summary of the issue: Historically, the indent in NVDA is reported via object model and its terminology is similar to what is found in Word's paragraph formatting dialog. In #12908, reporting indant via UIA has been introduced. A mapping between UIA text attributes relative to indent and the type of indent that is reported was used. This mapping was doing the following assumption: UIA first line indent corresponds to Word's first line indent UIA leading indent corresponds to Word's left indent UIA trailing indent corresponds to Word's right indent This assumption is not always correct for the first two points. And you can seen that object model access. And UIA access give not the same results in the following examples: left indent = 2.5cm and first line indent = 2.5cm left indent = 2.5cm and first line negative indent = 2.5cm Moreover, first line negative was reported in the object model code, whereas it does not appear at all in the UIA code, what evidences missing code. Description of how this pull request fixes the issue: Correct matching between Word's and UIA terminology has been implemented. To clarify: Word's terminology left indent = distance from the left margin to the left-most start of a line (it may be the first line or the following lines) right indent = distance from the right margin to the end of the paragraph's lines (except the last that may be incomplete) first line indent = distance between the start of the first line and the start of the other lines when the first line starts after the other ones hanging indent = distance between the start of the first line and the start of the other lines when the first line starts before the other ones UIA terminology first line indent = distance from the left margin to the start of the first line of the paragraph leading indent: distance from the left margin to the start of the following lines (2nd, 3rd, etc.) trailing indent = distance from the right margin to the end of the paragraph's lines (except the last that may be incomplete) Addition: do not report zero indent In addition, I have removed reporting any type of indent when its value is zero. Indeed, it was not reported in this case with the object model access, and I felt it was worth continuing in this way. Moreover, in #12908, nothing has been indicated that zero values should now be reported, so I assumed that it was unintentional. Possible alternative design I have aligned what is reported to what preexisted with the object model access, since in #12908 no information was indicating that it should have been modified. But another option may have been to report indentation as provided by UIA and to align the object model access code to what is provided by UIA. I have also not chosen this alternative design because I think that today, only Word provides indentation information via UIA. Thus, this makes sense to follow with Words conventions. If another provider should provide indent information one day, maybe the way indentation is reported should be reconsidered and uniformed. Should you however prefer this alternative design, just let me know. Testing strategy: Tested various paragraph formatting with non-zero left indent and the 3 following cases: no first line indent first line indent > 0 negative indent > 0
We have tried to switch to using UI automation to access MS Word documents by default in NVDA 2021.3. However, there are still several issues remaining with our UIA support. Switching to UIA by default should be held back until these are addressed. Some of these include: • Support for math: Support mathML UIA custom property in MS Word #12946 • Reporting of line numbers: Requires UIA custom patterns support\ Over the last couple of months our UIA support has had a lot of fixes and improvements, mainly spured on by the apparent need to switch due to NVDA and MS Word not playing well together with the introduction of Modern Comments in MS Word build 13901. However, a work around has been found for #12982 now, making the swich less of a high priority. Description of how this pull request fixes the issue: Reverts #12859 Reverts #12854 Reverts #12770
…#13437) Microsoft Word 2016 exposes a rich UI Automation implementation. For some time now, users have been able to optionally turn this on with an advanced setting. NVDA's support for MS Word via UIA has major performance advantages over the older object model support, so NVDA should use the UIA support by default where available. However, as the UIA implementation improved throughout Office 2016's lifetime, we should only enable our support for recent builds of Office 2016, specifically for build 15000 and higher, and when only on Windows 11. This was previously tried in pr #12770 but reverted in pr #12989 The main argument for reverting was the lack of math support, and ability to report line column and section numbers. These have all been since addressed. Description of how this pull request fixes the issue: NVDA now uses UI Automation to access Microsoft Word document controls by default when on Windows 11, for Microsoft Word version 16.0.15000 and higher. The Use UI Automation to access Microsoft Word document controls when available checkbox has been replaced with a combo box with the following values: • Default (where suitable) • Only where necessary: where the Microsoft Word object model is not available at all • Where suitable: Windows 11 / Microsoft Word version 16.0.15000 or higher, or where the Microsoft Word object model is unavailable • Always: where ever UI automation is available in Microsoft word (no matter how complete). If the older checkbox was previously checked, the setting will be set to Always.
Link to issue number:
None
Summary of the issue:
Microsoft Word 2016 exposes a rich UI Automation implementation. For some time now, users have been able to optionally turn this on with an advanced setting. NVDA's support for MS Word via UIA has major performance advantages over the older object model support, so NVDA should use the UIA support by default where available. However, as the UIA implementation improved throughout Office 2016's lifetime, we should only enable our support for recent builds of Office 2016, specifically for build 13901 and higher.
Description of how this pull request fixes the issue:
For a _WwG window that is found to have a native UI Automation implementation, the only situation where this UIA implementation will be ignored and therefore NVDA will fall back to the Office object model is: If it is an MS Office app, the build is < 13901, NVDA is able to inject in-process, and the user has not turned on
Always use UI Automation to access Microsoft Word document controls.The user guide has been updated to note that UIA will be used by default for MS Word version 13901 and higher.
Testing strategy:
Always use UI Automation to access Microsoft word document controls.Known issues with pull request:
None.
Change log entries:
Changes:
Use UI Automation to access Microsoft word document controlsadvanced setting on or off.Code Review Checklist: