When copying text from dialogs and windows via "screen review", separate lines are merged in one single line

[nvaccessAuto]

Reported by k_kolev1985 on 2014-02-20 08:04
From long time ago, I've noticed that text loaded in the "Virtual Revision" add-on for NVDA is not split on separate lines, but is displayed as one single line, even though on the screen the text is shown on separate lines. I thought that the issue is in the add-on itself, until a couple of days ago. I was demonstrating the "screen review" capabilities of NVDA in a Skype conference and then I've noticed that if I copy text from dialogs and windows via the "screen review" mode instead with the "object review" mode, the copied text is merged in one single line, even though it is copied (and shows on the screen) as separate lines. And not only that, but every line is joined to the other with no separation at all - not even a space. When I only review the text on the screen (even with "screen review" mode), the text is treated as it should - each line on its own - the merging occurs only when copying it. Note, that I'm talking about copying of text with NVDA+F9 and NVDA+F10.

Steps to reproduce it:

1. With NVDA running, open a dialog or window. For a dialog, even the "About NVDA" dialog of NVDA should do it. For a window, I've used the "Screen Resolution" window from the Control Panel.
2. Switch NVDA to "screen review" mode.
3. Start reviewing the text on the screen, via the text review commands.
4. Start selection of text on one line, via NVDA+F9.
5. Move one or more lines down and complete the selection, via NVDA+F10. The selected lines of text will be copied to the clipboard.
6. Paste the copied text in a text editor such as Notepad. You'll see that the lines of text are merged on one single line, rather than being each on its own line. And the merged lines have no separation between them - not even a space.
7. If you follow the steps above, but use the "object review" mode of NVDA to navigate through and copy text, the issue will not occur - each line of text will be on its own line.

Actual results: All lines of copied text are merged in one single line, with no separation at all (not even a space) between them.
Expected results: Each line of text should be on its own line.

NVDA version: next-10380,9ee9b11, but this occurs with 2013.3 as well. According to some users, this started in 2013.3. My guessing is that it has something to do with the "screen review" mode, because if I'm not mistaking, that mode was introduced then.

[nvaccessAuto]

Comment 1 by jteh on 2014-02-20 10:14
I suspect this actually broke in NVDA 2013.2 due to the massive changes to support right-to-left text.

Technical: It should be fairly simple to fix. DisplayModelTextInfo.clipboardText should use getTextInChunks and then join them with CRLF, similar to VirtualBufferTextInfo.clipboardText without the call to strip.
Changes:
Milestone changed from None to next

[nvaccessAuto]

Comment 2 by jteh on 2014-02-20 10:24
Btw, this might not fix the issue with the Virtual Revision add-on, depending on how it is implemented. My guess is that it just uses the text property, which isn't guaranteed to include line endings. (It used to for display model, but it doesn't any more.) It should probably use getTextInChunks.

[nvaccessAuto]

Comment 3 by Michael Curran <mick@... on 2014-02-20 23:14
In [6b74306]:

Merge branch 't3900' into next. Incubates #3900

Changes:
Added labels: incubating

[nvaccessAuto]

Comment 4 by mdcurran on 2014-02-20 23:16
I do have a call to strip, as I'm not entirely sure that we can guarantee that in all cases getTextInChunks will not yield text that does not contain cr or lf. This was according to a comment in geTextInChunks.

[nvaccessAuto]

Comment 5 by jteh on 2014-02-21 05:52
Ah, true. There is code in displayModel which does convert whitespace at the end of a line to a line feed. Originally, I wondered why this wasn't solving the problem, but I guess not all lines end with whitespace.

[nvaccessAuto]

Comment 6 by jteh on 2014-02-21 05:54
Mick, since we have to release rc2 for #3901, is this a candidate for rc2? It seems pretty low risk to me and it's a rather annoying regression, even though it happened two versions ago.

[nvaccessAuto]

Comment 7 by Michael Curran <mick@... on 2014-03-06 22:38
In [c6e3c33]:

Merge branch 't3900'. Fixes #3900

Changes:
Removed labels: incubating
State: closed

[nvaccessAuto]

Comment 8 by mdcurran on 2014-03-06 22:41
Changes:
Milestone changed from next to 2014.2