extensionPoints: Notify when NVDA is in browse mode

[nvdaes]

Is your feature request related to a problem? Please describe.

Add-ons may need to be notified when NVDA is in browse mode, for example to activate and deactivate profiles when entering and exiting browse mode, respectively.

Describe the solution you'd like

Add extensionPoints to notify when NVDA is in browse modeor not (i.e., in focus mode or not in a treeInterceptor).

Describe alternatives you've considered

Adda profile trigger for browse mode, which may take priority over the profile application trigger.

Additional context

Sometimes maybe useful to change voice settings to read in browse mode. This has been requested by a member of the spanish community on a Telegram group.

[XLTechie]

It would have to also include an Action to notify when NVDA is in focus mode in order to be effective. Possibly should include a globalVar for isInBrowseMode, so this can be determined dynamically without an extPoint being triggered.

[nvdaes]

I think that globalVars maybe deprecated in future. In addition, not just focus mode, but also when an object doesn't have a tree interceptor should be addressed.

[nvdaes]

Since this has been triaged, I may start working on this. For the primary purpose of this issue, notifying about changes in review.getReviewMode maybe appropriate.

[nvdaes]

But thinking more, imo a good approach maybe to add an extensionPoints.Action() to notify the state of the _set_passThrough method in the treeInterceptorHandler.TreeInterceptor class, notifying the state, and notifying False in api.getFocusObject function if focus doesn't have a tree interceptor. This action maybe called postBrowseModeSwitch. I'll test this approach. Additionally, a preBrowseModeSwitch maybe added to allow add-ons, for example, to decide if changes should be reported playing a sound, but I don't have a real use case for the pre action. El 13/09/2023 a las 13:38, Noelia Ruiz Martínez escribió:

…

Since this has been triaged, I may start working on this. For the primary purpose of this issue, notifying about changes in review.getReviewMode maybe appropriate.

[ramoncorominas]

Additionally, a preBrowseModeSwitch maybe added

to allow add-ons, for example, to decide if changes should be reported
playing a sound, but I don't have a real use case for the pre action.

Maybe an addon could use this to prevent switching to browse mode, for example in an Electron app, where (initially) the browse mode would make the app unusable. I'm thinking in VSCode, but certainly it uses browse mode for previewing markdown as HTML, but maybe other apps would benefit from this.

[nvdaes]

@ramoncorominas commented

Maybe an addon could use this to prevent switching to browse mode, for example in an Electron app

I don't know if this use case is valid, since profiles associated to apps may prevent switching to browse mode when the webpage is loaded. You may want to open a new issue to see if this proposal is accepted.

[ramoncorominas]

@nvdaes commented:

I don't know if this use case is valid, since profiles associated to apps may prevent switching to browse mode when the
webpage is loaded.

Sorry, it was not my intention to make a proposal, I was just trying to imagine a possible use case for preBrowseModeSwitch . I assume that not every Electron app would load a webpage somewhere, so I guess in those cases preventing browse mode would not harm.