Native selection mode has to be enabled for every browse mode instance

[LeonarddeR]

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

Native app selection is now bound to a single browse mode document. This means that you have to enable it explicitly after switching pages or windows.

Describe the solution you'd like

Save the state of native selection on the class, so its state persists until NVDA is restarted.

Describe alternatives you've considered

Add an option to browse mode config: "Use native app selection when supported". This ensures that a user can enable app selection by default for browse mode documents that support it.

[Adriani90]

This is related to new tabs and new websites as well. I suffices to press alt+left arrow when on a website so you go back, and the native selection mode is disabled.

[CyrilleB79]

While at it, I'd prefer to have this parameter stored in the config. I imagine that some people may want to have this permanently enabled, even after NVDA restarts.

Note that Jaws already performs such native copy by default, so it's not a feature targeting only a few experimented users. I have not checked if it is configurable or not in Jaws.

Anyway, it may make sense to have this feature enabled by default in the future, so a feature flag could be suitable for this parameter.

[seanbudd]

We'd like more feedback here before making a decision. The current behaviour matches single letter navigation mode.

[Adriani90]

I would also prefer an usual setting same as i.e. "automatic focus focusable elements" which you can enable and disable and which remains the same after restarting NVDA. the behavior on my side is as follows:

1. Open the browser with NVDA on
2. Press nva+shift+f10 to enable native selection mode
3. Press f5 to reload the page

Actual: the native selection mode is disabled after pressing f5 Expected: native selection mode should remain enabled and stored in the profile specific configuration.

[CyrilleB79]

I never disable single letter navigation, and I do not know if many people use this feature. It would be interesting to have feedback from people who use this feature for comparison. Maybe this feature also suffers from the refresh (F5) issue as described by @Adriani90 just above.

Anyway, my feeling that disabling single letter navigation may be useful for specific pages (e.g. web applications which have their own shortcuts), whereas it not useful on static webpages.

On the contrary, I cannot find any use case where enabling native selection and copy depends on the page being visited:

• either it's a global preference of the user (always on or always off)
• or it's really a case by case basis, depending not only on the source of the copy but also on the destination where the text should be copied
• or it may also be used to work with a sighted persons so that things can be highlighted by selection.

That are all the reasons why this parameter should not be tied to the current page.

Let's wait for feedback from other people.

.

[cary-rowen]

If possible, I would like to keep this option enabled.

[XLTechie]

Frankly, I'm not clear on why a user should ever prefer browse mode selection over this feature.

Isn't this what most users expect to be the result of selections? We usually have to explain to them why their selections are inferior, when they ask why this or that feature does not survive a copy and paste from a web page in browse mode.

Were it up to me, I would make this a global toggle in browse mode settings, default to on, with profile sensitivity. If a user turns it on, we shouldn't be turning it off again.

Actually no, I'll go further. I would make this the always-on behavior in contexts where it is supported. It is closer to the sighted experience, which is always our objective when possible, is it not?

Unless there is some downside I do not know of (I didn't follow the implementation of this feature).

[burmancomp]

Normal configuration option (or feature flag) with gesture and profile support. As to single letter navigation, f5 seems to switch it on at least in firefox.

[Adriani90]

yes the objective should be indeed to have the same experience as sighted people, so in my view there is no reason of having the old browse mode selection style available at all when native selection is supported.

[Adriani90]

In contrast, disabling the single letter navigation makes sense for specific websites which have their own shortcuts such as gmail or google drive, so you can use a combination of a browse mode lite and the shortcuts implemented by the web author for which you would have to enable focus mode otherwise. I found the issue #6682 which discusses this a bit. Now with the native selection mode even that use case is fixed in Firefox at least.

Note that by turning off single letter navigation you can type in edit fields and delete text without having to switch to focus mode. And you can read the label of edit fields even if the label is not associated properly with the edit field. Personally I find this feature very useful and it should be documented in more detail at the end of chapter 6.1 in the user guide.

[britechguy]

Frankly, I'm not clear on why a user should ever prefer browse mode selection over this feature.

Amen, amen, amen!! I know I'm sighted, but I don't think that has the slightest bearing on the fact that when I select something from a given webpage, e.g. a hyperlink, what I want is the hyperlink, not the link text, or when I select a headline that's in some huge font and with formatting, I want all of that preserved.

It is always possible on "the paste side of the equation" to paste without formatting if that happens to be desired, and I do use that feature quite a bit, but I am in complete control over when and how things paste. Right now, as things stand, I am not in control of how things copy in the way that they would if NVDA were not active at the time of copy, and it drives me insane. I've also seen it drive a lot of NVDA users who expect "a normal copy" as it has behaved all their lives as formerly sighted users vanish when NVDA becomes involved.

I want every possible thing that can behave "as it would were no screen reader involved" to behave that way when a screen reader is involved. I'd think that's what every Windows user would want and, indeed, expect. There has to be a very, very good reason for violation of this basic principle of consistent behavior with and without screen reader involvement.

It also needs to work under all web browsers, eventually, even if it's only Firefox at the moment.

[XLTechie]

Can anyone on this thread provide any reason at all why users might prefer browse mode selection? In all the time this conversation has been active, nobody has provided even one.

[michaelDCurran]

@XLTechie: Two reasons:

• There is some information in browse mode that will not be copied in native selection mode E.g. ARIA labels htat have been used as a fallback for content.
• Initially, I was not entirely confident the feature was full proof. Bugs either in Firefox or NVDA that stopped it from working in very particular scenarios like selecting content that contained an image.

If you are asking the question as someone who has been using selection mode significantly and have not hit any errors, then this is very encouraging and perhaps it's time to consider it being on by default and or permanently where supported.

[XLTechie]

@michaelDCurran I use it whenever I remember to turn it on. :) And whenever I don't get "Native selection mode unsupported in this document" for unknown reasons, like I'm getting at this moment on any GitHub PR page in 2024.3.

(updateAppSelection failed, no such interface supported COM errors)

While I can't say I've specifically ran it across images to test, I will try this. My normal uses--formatted text, tables, links--work quite well.