New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVDA freezes upon opening Log Viewer (NVDA+F1) after entering Word browse mode #6368

Closed
bhavyashah opened this Issue Sep 12, 2016 · 12 comments

Comments

Projects
None yet
6 participants
@bhavyashah

bhavyashah commented Sep 12, 2016

Steps to reproduce
Open a a fairly large Microsoft Word document.
Switch to browse mode by pressing NVDA+Space.
Try a slightly intensive document reading command such as initiating a say all.
Now, immediately press NVDA+F1 to open the Log Viewer.
Expected Result: The Log Viewer should open without any hitch and NVDA should report it.
Actual Result: There is a significant freeze during this time, and NVDA takes a while to respond and announce the opening of the Log Viewer and begin reading its contents despite having issued necessary reading commands already.

Test Environment
Microsoft Office Word 2010
NVDA version 2016.3
Document of 84 pages (more or less pages should be able to demonstrate this problem consistently as well)

In my observation, NVDA functions very slowly and unresponsively in Microsoft Word's browse mode. Since I usually deal with school textbooks which span up to a few hundreds of pages, and sometimes toggle browse mode to use NVDA's additional functionalities in that state, I have constantly marked this delay. It It is my belief that the freeze that I am describing relates more to a flawed or problematic Word browse mode implementation as opposed to deficiencies in the Log Viewer.

In any case, here is a snippet of the log that I consider pertinent to the issue at hand:
DEBUGWARNING - watchdog.watcher (10:17:12):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 190, in
File "core.pyo", line 384, in main
File "wx_core.pyo", line 8657, in MainLoop
File "wx_core.pyo", line 7952, in MainLoop
File "core.pyo", line 355, in Notify
File "queueHandler.pyo", line 83, in pumpAll
File "queueHandler.pyo", line 50, in flushQueue
File "scriptHandler.pyo", line 144, in queueScriptCallback
File "scriptHandler.pyo", line 186, in executeScript
File "globalCommands.pyo", line 1398, in script_navigatorObject_devInfo
File "logging__init
.pyo", line 1167, in info
File "logHandler.pyo", line 122, in _log
File "gui\logViewer.pyo", line 100, in activate
File "gui\logViewer.pyo", line 45, in init
File "gui\logViewer.pyo", line 54, in refresh
File "wx_core.pyo", line 13101, in AppendText

WARNING - watchdog.watcher (10:17:28):
Core frozen in stack:
File "nvda.pyw", line 190, in
File "core.pyo", line 384, in main
File "wx_core.pyo", line 8657, in MainLoop
File "wx_core.pyo", line 7952, in MainLoop
File "core.pyo", line 355, in Notify
File "queueHandler.pyo", line 83, in pumpAll
File "queueHandler.pyo", line 50, in flushQueue
File "scriptHandler.pyo", line 144, in queueScriptCallback
File "scriptHandler.pyo", line 186, in executeScript
File "globalCommands.pyo", line 1398, in script_navigatorObject_devInfo
File "logging__init
.pyo", line 1167, in info
File "logHandler.pyo", line 126, in _log
File "wx_core.pyo", line 13263, in SetInsertionPointEnd

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Sep 12, 2016

Contributor
Contributor

jcsteh commented Sep 12, 2016

@bhavyashah

This comment has been minimized.

Show comment
Hide comment
@bhavyashah

bhavyashah Sep 13, 2016

Hi Jamie,
Yes, the former issue is certainly the one of greater concern to me,
as in its current state, I only toggle to browse mode to use the quick
navigation key commands and the Elements list, and before resuming
navigation, I toggle back to focus mode and then continue browsing the
document.
Let me try to track down if any Document Formatting setting
contributes to this Word browse mode unresponsiveness.
Thanks.

On 9/13/16, James Teh notifications@github.com wrote:

I think two issues are being conflated here.

On one hand, you're talking about poor performance in Microsoft Word
browse mode itself. Word itself is fairly slow at providing information
to us, and the more document formatting settings you have enabled, the
worse it will be. There are limits to how much we can improve this. I'd
suggest disabling various document formatting settings to see if you can
figure out whether there is a particular culprit. If there is, please
provide further details.

On the other hand, you're talking about a freeze when you enter the log
viewer. It's hard to know whether this is because you're dealing with a
very large log file (which could certainly cause a freeze when opening
log viewer) or whether NVDA was still trying to fetch information from
Word and thus couldn't process the log viewer command. Either way, we
need to isolate and deal with one of these issues at a time. It sounds
like the former issue is the one of most concern to you.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#6368 (comment)

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

bhavyashah commented Sep 13, 2016

Hi Jamie,
Yes, the former issue is certainly the one of greater concern to me,
as in its current state, I only toggle to browse mode to use the quick
navigation key commands and the Elements list, and before resuming
navigation, I toggle back to focus mode and then continue browsing the
document.
Let me try to track down if any Document Formatting setting
contributes to this Word browse mode unresponsiveness.
Thanks.

On 9/13/16, James Teh notifications@github.com wrote:

I think two issues are being conflated here.

On one hand, you're talking about poor performance in Microsoft Word
browse mode itself. Word itself is fairly slow at providing information
to us, and the more document formatting settings you have enabled, the
worse it will be. There are limits to how much we can improve this. I'd
suggest disabling various document formatting settings to see if you can
figure out whether there is a particular culprit. If there is, please
provide further details.

On the other hand, you're talking about a freeze when you enter the log
viewer. It's hard to know whether this is because you're dealing with a
very large log file (which could certainly cause a freeze when opening
log viewer) or whether NVDA was still trying to fetch information from
Word and thus couldn't process the log viewer command. Either way, we
need to isolate and deal with one of these issues at a time. It sounds
like the former issue is the one of most concern to you.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#6368 (comment)

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Sep 13, 2016

Contributor
Contributor

jcsteh commented Sep 13, 2016

@bhavyashah

This comment has been minimized.

Show comment
Hide comment
@bhavyashah

bhavyashah Sep 13, 2016

Hi,
An updated discovery: All arrow keys individually, and Ctrl +
left/right arrows, work functionally well in browse mode (though there
is a minor, noticeable yet manageable latency greater than in focus
mode). However, paragraph navigation commands (Ctrl + up/down arrows)
in browse mode are consistently reproducing the freeze.
Note: Alt + up/down arrows do not respond back with sentence reading
speech from NVDA (likely part of a previous ticket I had filed about
slowness of sentence navigation even in slightly large documents), but
to be fair, they do not cause a freeze.
In conclusion, currently, I am able to primarily attribute these
freezes to be caused only while pressing a paragraph navigation key
command in Microsoft Word browse mode.
Thanks.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi Jamie,
Yes, the former issue is certainly the one of greater concern to me,
as in its current state, I only toggle to browse mode to use the quick
navigation key commands and the Elements list, and before resuming
navigation, I toggle back to focus mode and then continue browsing the
document.
Let me try to track down if any Document Formatting setting
contributes to this Word browse mode unresponsiveness.
Thanks.

On 9/13/16, James Teh notifications@github.com wrote:

I think two issues are being conflated here.

On one hand, you're talking about poor performance in Microsoft Word
browse mode itself. Word itself is fairly slow at providing information
to us, and the more document formatting settings you have enabled, the
worse it will be. There are limits to how much we can improve this. I'd
suggest disabling various document formatting settings to see if you can
figure out whether there is a particular culprit. If there is, please
provide further details.

On the other hand, you're talking about a freeze when you enter the log
viewer. It's hard to know whether this is because you're dealing with a
very large log file (which could certainly cause a freeze when opening
log viewer) or whether NVDA was still trying to fetch information from
Word and thus couldn't process the log viewer command. Either way, we
need to isolate and deal with one of these issues at a time. It sounds
like the former issue is the one of most concern to you.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#6368 (comment)

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

bhavyashah commented Sep 13, 2016

Hi,
An updated discovery: All arrow keys individually, and Ctrl +
left/right arrows, work functionally well in browse mode (though there
is a minor, noticeable yet manageable latency greater than in focus
mode). However, paragraph navigation commands (Ctrl + up/down arrows)
in browse mode are consistently reproducing the freeze.
Note: Alt + up/down arrows do not respond back with sentence reading
speech from NVDA (likely part of a previous ticket I had filed about
slowness of sentence navigation even in slightly large documents), but
to be fair, they do not cause a freeze.
In conclusion, currently, I am able to primarily attribute these
freezes to be caused only while pressing a paragraph navigation key
command in Microsoft Word browse mode.
Thanks.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi Jamie,
Yes, the former issue is certainly the one of greater concern to me,
as in its current state, I only toggle to browse mode to use the quick
navigation key commands and the Elements list, and before resuming
navigation, I toggle back to focus mode and then continue browsing the
document.
Let me try to track down if any Document Formatting setting
contributes to this Word browse mode unresponsiveness.
Thanks.

On 9/13/16, James Teh notifications@github.com wrote:

I think two issues are being conflated here.

On one hand, you're talking about poor performance in Microsoft Word
browse mode itself. Word itself is fairly slow at providing information
to us, and the more document formatting settings you have enabled, the
worse it will be. There are limits to how much we can improve this. I'd
suggest disabling various document formatting settings to see if you can
figure out whether there is a particular culprit. If there is, please
provide further details.

On the other hand, you're talking about a freeze when you enter the log
viewer. It's hard to know whether this is because you're dealing with a
very large log file (which could certainly cause a freeze when opening
log viewer) or whether NVDA was still trying to fetch information from
Word and thus couldn't process the log viewer command. Either way, we
need to isolate and deal with one of these issues at a time. It sounds
like the former issue is the one of most concern to you.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#6368 (comment)

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

@bhavyashah

This comment has been minimized.

Show comment
Hide comment
@bhavyashah

bhavyashah Sep 13, 2016

Hi Jamie,
No, Microsoft Word's focus mode works perfectly well, and as I stated
in my previous message, most navigation commands also work
comparatively slower than focus mode, but still manageably well.
Paragraph navigation in browse mode seems to be the problem, somehow.
Perhaps, this log snippet might give you more information...
DEBUGWARNING - watchdog._watcher (09:40:40):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 190, in
File "core.pyo", line 384, in main
File "wx_core.pyo", line 8657, in MainLoop
File "wx_core.pyo", line 7952, in MainLoop
File "core.pyo", line 355, in Notify
File "queueHandler.pyo", line 83, in pumpAll
File "queueHandler.pyo", line 50, in flushQueue
File "scriptHandler.pyo", line 144, in _queueScriptCallback
File "scriptHandler.pyo", line 186, in executeScript
File "cursorManager.pyo", line 211, in script_moveByParagraph_forward
File "cursorManager.pyo", line 124, in caretMovementScriptHelper
File "treeInterceptorHandler.pyo", line 185, in move
File "NVDAObjects\window\winword.pyo", line 817, in move
File "NVDAObjects\window\winword.pyo", line 811, in move
File "comtypesMonkeyPatches.pyo", line 35, in new__getattr

File "comtypes\client\lazybind.pyo", line 149, in getattr
File "comtypes\automation.pyo", line 664, in _invoke
File "IAccessibleHandler.pyo", line 596, in winEventCallback
File "winUser.pyo", line 409, in getClassName

DEBUGWARNING - scriptHandler.executeScript (09:40:40):
error executing script: <bound method
WordDocumentTreeInterceptor.script_moveByParagraph_forward of
<NVDAObjects.window.winword.WordDocumentTreeInterceptor object at
0x04954950>> with gesture u'ctrl+down arrow'
Traceback (most recent call last):
File "scriptHandler.pyo", line 186, in executeScript
File "cursorManager.pyo", line 211, in script_moveByParagraph_forward
File "cursorManager.pyo", line 124, in _caretMovementScriptHelper
File "treeInterceptorHandler.pyo", line 185, in move
File "NVDAObjects\window\winword.pyo", line 817, in move
File "NVDAObjects\window\winword.pyo", line 811, in _move
File "watchdog.pyo", line 202, in _COMError_init
CallCancelled

Also, to resolve the freeze, I usually need to Alt Tab back to my
document, and then in a couple of seconds, NVDA should resume normalcy
again. All the same, this reproduction method is proving to be quite
consistent at my end.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi,
An updated discovery: All arrow keys individually, and Ctrl +
left/right arrows, work functionally well in browse mode (though there
is a minor, noticeable yet manageable latency greater than in focus
mode). However, paragraph navigation commands (Ctrl + up/down arrows)
in browse mode are consistently reproducing the freeze.
Note: Alt + up/down arrows do not respond back with sentence reading
speech from NVDA (likely part of a previous ticket I had filed about
slowness of sentence navigation even in slightly large documents), but
to be fair, they do not cause a freeze.
In conclusion, currently, I am able to primarily attribute these
freezes to be caused only while pressing a paragraph navigation key
command in Microsoft Word browse mode.
Thanks.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi Jamie,
Yes, the former issue is certainly the one of greater concern to me,
as in its current state, I only toggle to browse mode to use the quick
navigation key commands and the Elements list, and before resuming
navigation, I toggle back to focus mode and then continue browsing the
document.
Let me try to track down if any Document Formatting setting
contributes to this Word browse mode unresponsiveness.
Thanks.

On 9/13/16, James Teh notifications@github.com wrote:

I think two issues are being conflated here.

On one hand, you're talking about poor performance in Microsoft Word
browse mode itself. Word itself is fairly slow at providing information
to us, and the more document formatting settings you have enabled, the
worse it will be. There are limits to how much we can improve this. I'd
suggest disabling various document formatting settings to see if you can
figure out whether there is a particular culprit. If there is, please
provide further details.

On the other hand, you're talking about a freeze when you enter the log
viewer. It's hard to know whether this is because you're dealing with a
very large log file (which could certainly cause a freeze when opening
log viewer) or whether NVDA was still trying to fetch information from
Word and thus couldn't process the log viewer command. Either way, we
need to isolate and deal with one of these issues at a time. It sounds
like the former issue is the one of most concern to you.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#6368 (comment)

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

bhavyashah commented Sep 13, 2016

Hi Jamie,
No, Microsoft Word's focus mode works perfectly well, and as I stated
in my previous message, most navigation commands also work
comparatively slower than focus mode, but still manageably well.
Paragraph navigation in browse mode seems to be the problem, somehow.
Perhaps, this log snippet might give you more information...
DEBUGWARNING - watchdog._watcher (09:40:40):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 190, in
File "core.pyo", line 384, in main
File "wx_core.pyo", line 8657, in MainLoop
File "wx_core.pyo", line 7952, in MainLoop
File "core.pyo", line 355, in Notify
File "queueHandler.pyo", line 83, in pumpAll
File "queueHandler.pyo", line 50, in flushQueue
File "scriptHandler.pyo", line 144, in _queueScriptCallback
File "scriptHandler.pyo", line 186, in executeScript
File "cursorManager.pyo", line 211, in script_moveByParagraph_forward
File "cursorManager.pyo", line 124, in caretMovementScriptHelper
File "treeInterceptorHandler.pyo", line 185, in move
File "NVDAObjects\window\winword.pyo", line 817, in move
File "NVDAObjects\window\winword.pyo", line 811, in move
File "comtypesMonkeyPatches.pyo", line 35, in new__getattr

File "comtypes\client\lazybind.pyo", line 149, in getattr
File "comtypes\automation.pyo", line 664, in _invoke
File "IAccessibleHandler.pyo", line 596, in winEventCallback
File "winUser.pyo", line 409, in getClassName

DEBUGWARNING - scriptHandler.executeScript (09:40:40):
error executing script: <bound method
WordDocumentTreeInterceptor.script_moveByParagraph_forward of
<NVDAObjects.window.winword.WordDocumentTreeInterceptor object at
0x04954950>> with gesture u'ctrl+down arrow'
Traceback (most recent call last):
File "scriptHandler.pyo", line 186, in executeScript
File "cursorManager.pyo", line 211, in script_moveByParagraph_forward
File "cursorManager.pyo", line 124, in _caretMovementScriptHelper
File "treeInterceptorHandler.pyo", line 185, in move
File "NVDAObjects\window\winword.pyo", line 817, in move
File "NVDAObjects\window\winword.pyo", line 811, in _move
File "watchdog.pyo", line 202, in _COMError_init
CallCancelled

Also, to resolve the freeze, I usually need to Alt Tab back to my
document, and then in a couple of seconds, NVDA should resume normalcy
again. All the same, this reproduction method is proving to be quite
consistent at my end.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi,
An updated discovery: All arrow keys individually, and Ctrl +
left/right arrows, work functionally well in browse mode (though there
is a minor, noticeable yet manageable latency greater than in focus
mode). However, paragraph navigation commands (Ctrl + up/down arrows)
in browse mode are consistently reproducing the freeze.
Note: Alt + up/down arrows do not respond back with sentence reading
speech from NVDA (likely part of a previous ticket I had filed about
slowness of sentence navigation even in slightly large documents), but
to be fair, they do not cause a freeze.
In conclusion, currently, I am able to primarily attribute these
freezes to be caused only while pressing a paragraph navigation key
command in Microsoft Word browse mode.
Thanks.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi Jamie,
Yes, the former issue is certainly the one of greater concern to me,
as in its current state, I only toggle to browse mode to use the quick
navigation key commands and the Elements list, and before resuming
navigation, I toggle back to focus mode and then continue browsing the
document.
Let me try to track down if any Document Formatting setting
contributes to this Word browse mode unresponsiveness.
Thanks.

On 9/13/16, James Teh notifications@github.com wrote:

I think two issues are being conflated here.

On one hand, you're talking about poor performance in Microsoft Word
browse mode itself. Word itself is fairly slow at providing information
to us, and the more document formatting settings you have enabled, the
worse it will be. There are limits to how much we can improve this. I'd
suggest disabling various document formatting settings to see if you can
figure out whether there is a particular culprit. If there is, please
provide further details.

On the other hand, you're talking about a freeze when you enter the log
viewer. It's hard to know whether this is because you're dealing with a
very large log file (which could certainly cause a freeze when opening
log viewer) or whether NVDA was still trying to fetch information from
Word and thus couldn't process the log viewer command. Either way, we
need to isolate and deal with one of these issues at a time. It sounds
like the former issue is the one of most concern to you.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#6368 (comment)

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

@bhavyashah

This comment has been minimized.

Show comment
Hide comment
@bhavyashah

bhavyashah Sep 13, 2016

Hi Jamie,
I tried unchecking all Document Formatting settings, and general
navigation in both focus and browse mode seemed snappier, as you had
informed earlier. However, paragraph navigation in browse mode still
causes NVDA to freeze consistently, even with all Document Formatting
settings disabled.
Thanks.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi Jamie,
No, Microsoft Word's focus mode works perfectly well, and as I stated
in my previous message, most navigation commands also work
comparatively slower than focus mode, but still manageably well.
Paragraph navigation in browse mode seems to be the problem, somehow.
Perhaps, this log snippet might give you more information...
DEBUGWARNING - watchdog._watcher (09:40:40):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 190, in
File "core.pyo", line 384, in main
File "wx_core.pyo", line 8657, in MainLoop
File "wx_core.pyo", line 7952, in MainLoop
File "core.pyo", line 355, in Notify
File "queueHandler.pyo", line 83, in pumpAll
File "queueHandler.pyo", line 50, in flushQueue
File "scriptHandler.pyo", line 144, in _queueScriptCallback
File "scriptHandler.pyo", line 186, in executeScript
File "cursorManager.pyo", line 211, in script_moveByParagraph_forward
File "cursorManager.pyo", line 124, in caretMovementScriptHelper
File "treeInterceptorHandler.pyo", line 185, in move
File "NVDAObjects\window\winword.pyo", line 817, in move
File "NVDAObjects\window\winword.pyo", line 811, in move
File "comtypesMonkeyPatches.pyo", line 35, in new__getattr

File "comtypes\client\lazybind.pyo", line 149, in getattr
File "comtypes\automation.pyo", line 664, in _invoke
File "IAccessibleHandler.pyo", line 596, in winEventCallback
File "winUser.pyo", line 409, in getClassName

DEBUGWARNING - scriptHandler.executeScript (09:40:40):
error executing script: <bound method
WordDocumentTreeInterceptor.script_moveByParagraph_forward of
<NVDAObjects.window.winword.WordDocumentTreeInterceptor object at
0x04954950>> with gesture u'ctrl+down arrow'
Traceback (most recent call last):
File "scriptHandler.pyo", line 186, in executeScript
File "cursorManager.pyo", line 211, in script_moveByParagraph_forward
File "cursorManager.pyo", line 124, in _caretMovementScriptHelper
File "treeInterceptorHandler.pyo", line 185, in move
File "NVDAObjects\window\winword.pyo", line 817, in move
File "NVDAObjects\window\winword.pyo", line 811, in _move
File "watchdog.pyo", line 202, in _COMError_init
CallCancelled

Also, to resolve the freeze, I usually need to Alt Tab back to my
document, and then in a couple of seconds, NVDA should resume normalcy
again. All the same, this reproduction method is proving to be quite
consistent at my end.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi,
An updated discovery: All arrow keys individually, and Ctrl +
left/right arrows, work functionally well in browse mode (though there
is a minor, noticeable yet manageable latency greater than in focus
mode). However, paragraph navigation commands (Ctrl + up/down arrows)
in browse mode are consistently reproducing the freeze.
Note: Alt + up/down arrows do not respond back with sentence reading
speech from NVDA (likely part of a previous ticket I had filed about
slowness of sentence navigation even in slightly large documents), but
to be fair, they do not cause a freeze.
In conclusion, currently, I am able to primarily attribute these
freezes to be caused only while pressing a paragraph navigation key
command in Microsoft Word browse mode.
Thanks.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi Jamie,
Yes, the former issue is certainly the one of greater concern to me,
as in its current state, I only toggle to browse mode to use the quick
navigation key commands and the Elements list, and before resuming
navigation, I toggle back to focus mode and then continue browsing the
document.
Let me try to track down if any Document Formatting setting
contributes to this Word browse mode unresponsiveness.
Thanks.

On 9/13/16, James Teh notifications@github.com wrote:

I think two issues are being conflated here.

On one hand, you're talking about poor performance in Microsoft Word
browse mode itself. Word itself is fairly slow at providing information
to us, and the more document formatting settings you have enabled, the
worse it will be. There are limits to how much we can improve this. I'd
suggest disabling various document formatting settings to see if you
can
figure out whether there is a particular culprit. If there is, please
provide further details.

On the other hand, you're talking about a freeze when you enter the log
viewer. It's hard to know whether this is because you're dealing with a
very large log file (which could certainly cause a freeze when opening
log viewer) or whether NVDA was still trying to fetch information from
Word and thus couldn't process the log viewer command. Either way, we
need to isolate and deal with one of these issues at a time. It sounds
like the former issue is the one of most concern to you.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#6368 (comment)

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

bhavyashah commented Sep 13, 2016

Hi Jamie,
I tried unchecking all Document Formatting settings, and general
navigation in both focus and browse mode seemed snappier, as you had
informed earlier. However, paragraph navigation in browse mode still
causes NVDA to freeze consistently, even with all Document Formatting
settings disabled.
Thanks.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi Jamie,
No, Microsoft Word's focus mode works perfectly well, and as I stated
in my previous message, most navigation commands also work
comparatively slower than focus mode, but still manageably well.
Paragraph navigation in browse mode seems to be the problem, somehow.
Perhaps, this log snippet might give you more information...
DEBUGWARNING - watchdog._watcher (09:40:40):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 190, in
File "core.pyo", line 384, in main
File "wx_core.pyo", line 8657, in MainLoop
File "wx_core.pyo", line 7952, in MainLoop
File "core.pyo", line 355, in Notify
File "queueHandler.pyo", line 83, in pumpAll
File "queueHandler.pyo", line 50, in flushQueue
File "scriptHandler.pyo", line 144, in _queueScriptCallback
File "scriptHandler.pyo", line 186, in executeScript
File "cursorManager.pyo", line 211, in script_moveByParagraph_forward
File "cursorManager.pyo", line 124, in caretMovementScriptHelper
File "treeInterceptorHandler.pyo", line 185, in move
File "NVDAObjects\window\winword.pyo", line 817, in move
File "NVDAObjects\window\winword.pyo", line 811, in move
File "comtypesMonkeyPatches.pyo", line 35, in new__getattr

File "comtypes\client\lazybind.pyo", line 149, in getattr
File "comtypes\automation.pyo", line 664, in _invoke
File "IAccessibleHandler.pyo", line 596, in winEventCallback
File "winUser.pyo", line 409, in getClassName

DEBUGWARNING - scriptHandler.executeScript (09:40:40):
error executing script: <bound method
WordDocumentTreeInterceptor.script_moveByParagraph_forward of
<NVDAObjects.window.winword.WordDocumentTreeInterceptor object at
0x04954950>> with gesture u'ctrl+down arrow'
Traceback (most recent call last):
File "scriptHandler.pyo", line 186, in executeScript
File "cursorManager.pyo", line 211, in script_moveByParagraph_forward
File "cursorManager.pyo", line 124, in _caretMovementScriptHelper
File "treeInterceptorHandler.pyo", line 185, in move
File "NVDAObjects\window\winword.pyo", line 817, in move
File "NVDAObjects\window\winword.pyo", line 811, in _move
File "watchdog.pyo", line 202, in _COMError_init
CallCancelled

Also, to resolve the freeze, I usually need to Alt Tab back to my
document, and then in a couple of seconds, NVDA should resume normalcy
again. All the same, this reproduction method is proving to be quite
consistent at my end.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi,
An updated discovery: All arrow keys individually, and Ctrl +
left/right arrows, work functionally well in browse mode (though there
is a minor, noticeable yet manageable latency greater than in focus
mode). However, paragraph navigation commands (Ctrl + up/down arrows)
in browse mode are consistently reproducing the freeze.
Note: Alt + up/down arrows do not respond back with sentence reading
speech from NVDA (likely part of a previous ticket I had filed about
slowness of sentence navigation even in slightly large documents), but
to be fair, they do not cause a freeze.
In conclusion, currently, I am able to primarily attribute these
freezes to be caused only while pressing a paragraph navigation key
command in Microsoft Word browse mode.
Thanks.

On 9/13/16, Bhavya shah bhavya.shah125@gmail.com wrote:

Hi Jamie,
Yes, the former issue is certainly the one of greater concern to me,
as in its current state, I only toggle to browse mode to use the quick
navigation key commands and the Elements list, and before resuming
navigation, I toggle back to focus mode and then continue browsing the
document.
Let me try to track down if any Document Formatting setting
contributes to this Word browse mode unresponsiveness.
Thanks.

On 9/13/16, James Teh notifications@github.com wrote:

I think two issues are being conflated here.

On one hand, you're talking about poor performance in Microsoft Word
browse mode itself. Word itself is fairly slow at providing information
to us, and the more document formatting settings you have enabled, the
worse it will be. There are limits to how much we can improve this. I'd
suggest disabling various document formatting settings to see if you
can
figure out whether there is a particular culprit. If there is, please
provide further details.

On the other hand, you're talking about a freeze when you enter the log
viewer. It's hard to know whether this is because you're dealing with a
very large log file (which could certainly cause a freeze when opening
log viewer) or whether NVDA was still trying to fetch information from
Word and thus couldn't process the log viewer command. Either way, we
need to isolate and deal with one of these issues at a time. It sounds
like the former issue is the one of most concern to you.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#6368 (comment)

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

Warm Regards
Bhavya Shah
Using NVDA (Non Visual Desktop Access) free and open source screen
reader for Microsoft Windows
To download a copy of the free screen reader NVDA, please visit
http://www.nvaccess.org/
Using Google Talkback on Motorolla G second generation Lollipop 5.0.2
Reach me through the following means:
Mobile: +91 7506221750
E-mail id: bhavya.shah125@gmail.com
Skype id : bhavya.09

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Oct 28, 2016

Contributor

@bhavyashah is it possible for you to provide an example Word document that exhibits the "freeze on paragraph navigation while in browse mode" behaviour?

Contributor

feerrenrut commented Oct 28, 2016

@bhavyashah is it possible for you to provide an example Word document that exhibits the "freeze on paragraph navigation while in browse mode" behaviour?

@bhavyashah

This comment has been minimized.

Show comment
Hide comment
@bhavyashah

bhavyashah Oct 28, 2016

This document is long enough to help replicate the afore described freeze - Three Men in a Boat.docx

bhavyashah commented Oct 28, 2016

This document is long enough to help replicate the afore described freeze - Three Men in a Boat.docx

@feerrenrut feerrenrut added the p1 label Nov 3, 2016

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Nov 3, 2016

Contributor

I can reproduce this using the document provided with MS Word 2013, with a recent "next" build of NVDA (next-13637,233fa85b).

P1 to try and understand the cause of this issue. Then re-prioritise.

EDIT:
I was unable to reproduce the issue when opening the Log Viewer while using the read all command while in browse mode. I did however reproduce the other issue mentioned in a comment about moving by paragraph (ctrl+down arrow) while in browse mode.

Contributor

feerrenrut commented Nov 3, 2016

I can reproduce this using the document provided with MS Word 2013, with a recent "next" build of NVDA (next-13637,233fa85b).

P1 to try and understand the cause of this issue. Then re-prioritise.

EDIT:
I was unable to reproduce the issue when opening the Log Viewer while using the read all command while in browse mode. I did however reproduce the other issue mentioned in a comment about moving by paragraph (ctrl+down arrow) while in browse mode.

@feerrenrut feerrenrut self-assigned this Dec 1, 2016

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Dec 2, 2016

Contributor

Technical:
The freeze while moving by paragraph is being caused by self.obj.WinwordDocumentObject.characters.count in the _move function of the WordDocumentTextInfo class in winword.py.

Removing this check results in the move by paragraph in browse mode taking the same amount of time as in focus mode. There is some delay that affects both modes. When moving by paragraph the cursor can be seen to flash many times, as if it is moving multiple times. This might be worth looking into.

Contributor

feerrenrut commented Dec 2, 2016

Technical:
The freeze while moving by paragraph is being caused by self.obj.WinwordDocumentObject.characters.count in the _move function of the WordDocumentTextInfo class in winword.py.

Removing this check results in the move by paragraph in browse mode taking the same amount of time as in focus mode. There is some delay that affects both modes. When moving by paragraph the cursor can be seen to flash many times, as if it is moving multiple times. This might be worth looking into.

@michaelDCurran

This comment has been minimized.

Show comment
Hide comment
@michaelDCurran

michaelDCurran Dec 6, 2016

Contributor

@feerrenrut: you could try replacing

WinwordDocumentObject.characters.count

with

WinwordDocumentObject.range().end 

This should result in the same number... in deed I'd argue this way is also more in the spirit of the if check anyway, I.e. detecting the end of the document.

I cannot reproduce the freeze properly so can't test myself.

Contributor

michaelDCurran commented Dec 6, 2016

@feerrenrut: you could try replacing

WinwordDocumentObject.characters.count

with

WinwordDocumentObject.range().end 

This should result in the same number... in deed I'd argue this way is also more in the spirit of the if check anyway, I.e. detecting the end of the document.

I cannot reproduce the freeze properly so can't test myself.

@derekriemer

This comment has been minimized.

Show comment
Hide comment
@derekriemer

derekriemer Dec 6, 2016

Collaborator
Collaborator

derekriemer commented Dec 6, 2016

feerrenrut added a commit that referenced this issue Dec 7, 2016

Stop word from freezing
When moving by paragraph while in browse mode of a large document.

Fix for #6368

feerrenrut added a commit that referenced this issue Dec 7, 2016

incubates #6623
Issue #6368
Merge branch 'i6368-WordFreeze' into next

@nvaccessAuto nvaccessAuto added this to the 2017.1 milestone Dec 30, 2016

feerrenrut added a commit that referenced this issue Dec 30, 2016

Update changes file for PR #6623
Fix freeze in Microsoft Word when moving by paragraph through a large document while in browse mode. (Issue #6368)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment