Have you tested this in Excel as well as along with the "Enable browse mode on page load" option disabled?

Note that in cases where browse mode is off by default, which is always the case in MS Word, there is no tree interceptor, so there is no script and no elements list until you have enabled browse mode for the first time.
On the other hand, in Microsoft Excel, the tree interceptor is force created en de elements list is also available in focus mode..

Ugh, my firefox bounced focus there.

@LeonarddeR, nope, I must confess I mostly had browsers in mind as this feature is actually ported from WebAccess where our users did request this change a while back.
Thanks for the precision, I'll thoroughly test Word and Excel and report my results here.
Would you know of other BrowseModeTreeInterceptor implementations that might require special attention?

@Brian1Gaff, I guess you are referring to #10379

@LeonarddeR we actually did not bother switching back to browse mode when setting ignoreTreeInterceptorPassThrough = True on the elementsList script in WebAccess, but I felt it would be more comprehensive that way. Seems I did not think it enough, as I'm far from being an expert on Word and Excel implementations.
Maybe should I try the following alternative approach:

• Not switching modes at all prior to opening the dialog.
• Alter TextInfoQuickNavItem.moveTo so that if attempting to move to a not focusable place then switch to browse mode.

What do you think?

Btw. I just noticed ElementsListDialog.onAction does not care about #8831 as does BrowseModeTreeInterceptor._quickNavScript. Thus, I guess we should report before moving in the Elements List as well.

@JulienCochuyt wrote;

What do you think?

I think that's better. It also means that if automatic focus mode is enabled, invoking the elements list and then focussing an element doesn't have to switch on browse mode at all.

Btw. I just noticed ElementsListDialog.onAction does not care about #8831 as does BrowseModeTreeInterceptor._quickNavScript. Thus, I guess we should report before moving in the Elements List as well.

Why report before moving in? I don't think that's very important.

@LeonarddeR wrote:

Why report before moving in? I don't think that's very important.

The comment from Jamie on 2019-10-21 in BrowseModeTreeInterceptor._quickNavScript as of PR #10389 says:
(I hadn't noticed how recent it was before blaming it for reference here.)

#8831: Report before moving because moving might change the focus, which
might mutate the document, potentially invalidating info if it is
offset-based.

I agree switching to browse mode only when moving to, if necessary, is the better way to go. I would not have liked switching to browse mode when opening the dialog.