Opened 4 years ago

Last modified 4 years ago

#1358 new defect

NVDA reports selection incorectly in VS 2008 code editor

Reported by: aleksey_s Owned by:
Priority: minor Milestone:
Component: Core Version: master
Keywords: Cc:
Operating system: Blocked by:
Blocking:
Changes document entry (for developers):

Description

STR:

  • open vs 2008
  • file->new->file
  • choose a c++ file template
  • type something like
    #include <iostream>
    
  • press "enter" to create new line
  • navigate up to place cursor on the first line
  • press shift+end

Actual results:
NVDA announces "#include <iostream"
Expected results:
NVDA should announce "#include <iostream>"

Change History (4)

comment:1 follow-up: Changed 4 years ago by aleksey_s

There also is another issue with reporting selection in that editor. when you adjust already existing selection, NVDA reports it twice: firstly the new selection, then the old one.

This raises a question whether EditableTextWithoutAutoselectDetection was correctly chosen as a base class for the control. What events object is expected to fire for auto select detection to work?

I contacted original author of the app module without any response.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 4 years ago by jteh

Replying to aleksey_s:

This raises a question whether EditableTextWithoutAutoselectDetection was correctly chosen as a base class for the control.

This means that NVDA just detects selection changes when you press selection keys. Events are not used. If this is reporting double changes, there is most likely a bug in the TextInfo implementation somewhere. You should debug this before addressing the following question.

What events object is expected to fire for auto select detection to work?

See the NVDAObjects.behaviors.EditableTextWithAutoSelectDetection class. We now know it fires valueChange, so generally, you'd make valueChange call textChange.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 4 years ago by aleksey_s

Replying to jteh:

This means that NVDA just detects selection changes when you press selection keys. Events are not used.

So it will not be able to detect selection if done with mouse, or programmatically, right?

If this is reporting double changes, there is most likely a bug in the TextInfo implementation somewhere. You should debug this before addressing the following question.

There definitely are bugs in TextInfo implementation, e.g. seems that in vs API offsets are calculated from 1, not from 0, but TextInfo code isn't always aware of it. Finally, I think that VsTextEditPaneTextInfo doesn't need to be derived from OffsetsTextInfo, since it can expand to word by using vs API and so on, with lesser number of calls to the API. However, I am not so good with understanding the basic TextInfo. Currently, OfssetsTextInfo is easier to understand for me.

Anyway, I am not sure how this can affect select detection so that it reports twice. the VsTextEditPaneTextInfo doesn't manage when to report selection changes, it just informs about selection offsets when requested by OffsetsTextInfo.

comment:4 in reply to: ↑ 3 Changed 4 years ago by jteh

Replying to aleksey_s:

Anyway, I am not sure how this can affect select detection so that it reports twice.

I'm not really sure either. The script you're interested in is editableText.EditableTextWithoutAutoSelectDetection.script_caret_changeSelection. In short, it fetches the old selection, sends the key, fetches the new one and sends them off to be compared/spoken. If the old selection is somehow wrong or the offsets change, it can cause problems. I suggest you start debugging by looking at the offsets of the old and new selections.

Note: See TracTickets for help on using tickets.