Comment 1 by jteh on 2013-04-15 22:20
(From ticket:2701#comment:6):

I know of one issue where if you press end, Gecko moves you to the end of the line, but this position is exposed as being equivalent to the start of the next line. Therefore, NVDA will see the current line as the next line instead of the real current line. When you use up and down arrows, you will stay in this position, so everything gets messed up. This only happens if you press end, though. We've known about this for years, but haven't been able to come up with a solution yet.

It'd be good if you could confirm this fits your first issue.

As for the issue regarding duplicate words, I'm not sure about this one, though it may relate to an issue with Firefox when there is punctuation near the current word. This might give you some idea how to reproduce this reliably. If you do find a way to reproduce it reliably, please comment.

Comment 3 by camlorn on 2013-04-16 02:17
Nope. Pressing end isn't reliably reproducing it. I'll comment if I can figure out what does. It's extremely annoying when it happens, though.

Comment 4 by camlorn on 2013-04-26 01:32
I've not yet managed to reproduce the duplicate lines problem.
I have, however, managed to almost reliably reproduce the duplicate words problem, and can provide more information.
It's not lines. It's indented paragraphs. The quickest way to reproduce it is to find a multiline edit field, type something that's multiple words--such as the contents of this comment--press enter, space 4 times, type a second paragraph. The actual number of spaces doesn't appear to matter.
Move across the boundary between the first and second indented paragraph (only seems to happen if you indent). Observe that the last word of the previous paragraph is the first word of the next one. It doesn't seem to matter which way you come at it, whether from the left or the right, and it doesn't seem to be happening when navigating by character.
It also happens in Thunderbird.
The lines part of this seems to be coming and going, and I have had no luck getting it to reliably happen. I've also had no luck in figuring out how to get it to stop reliably when it starts, at least not without refreshing the page, which would be useful info in and of itself.
Changes:
Changed title from "firefox edit fields: duplicate llines" to "firefox edit fields: duplicate llines and words"

Comment 5 by jteh on 2013-04-26 01:56
The issue you mention with duplicate words and indentation is MozillaBug:812187, which appears to be fixed in Firefox 23 (nightly).

As for duplicate lines, I still suspect what I said in comment:1 about the position at the end of the line. If you see duplicate lines again, press home and see if it goes away. Note that contrary to my comment, it seems that pressing end isn't the only way to reproduce this. I suspect you can land on the end of line position if your position in the current line is after the end of the previous line; i.e. the previous line is shorter.

Comment 6 by a11cf0.vk on 2013-05-11 12:27
This may be a different problem, but i will describe it here.
My problem is similar to the problem in this ticket, but in my case NVDA randomly duplicates lines not in edit fields, but just in any place of browse mode.
Also, NVDA sometimes reads a completely unrelated line instead of the previous or next one when navigating in browse mode.
This behaviour is unpredictable and i can't reliably reproduce it, but is very annoying.
This problem occurs not only in Firefox, but also in Ie and possibly in other browsers.

Comment 7 by jteh on 2013-06-07 05:53
I've created a branch to fix this: ia2EolCaret. Mick, I'd appreciate your code review. :)

@camlorn, it'd be good if you can give this try build a spin to see if it fixes your repeated lines issue:
http://community.nvda-project.org/try/ia2EolCaret/nvda_snapshot_try-ia2EolCaret-9265,859fdf9.exe

I also filed MozillaBug:880159 to make character and word reporting more appropriate at the end of a line.
Changes:
Milestone changed from None to near-term

Comment 8 by jteh (in reply to comment 6) on 2013-06-07 05:54
Replying to a11cf0.vk:

My problem is similar to the problem in this ticket, but in my case NVDA randomly duplicates lines not in edit fields, but just in any place of browse mode.

This is unrelated to this ticket. It might be #2039.

Comment 9 by jteh (in reply to comment 7) on 2013-06-25 07:34
Replying to jteh:

I also filed MozillaBug:880159 to make character and word reporting more appropriate at the end of a line.

For character, our current proposal is that Mozilla should return a collapsed range. I just tested whether that would work in NVDA. It does say "blank". However, the problem is that move(UNIT_CHARACTER, 1) won't move past that point. I don't think this affects any current code, but it's probably still bad. Mick, thoughts?

@jcsteh I guess this is still an issue in last Firefox version. Right?
@camlorn please proviede exact stept to reproduce and an example website. I think there are some duplicate issue out there but we need exact steps to reproduce here.

This issue still exists, yes. However, the necessary changes need to be made in NVDA, not Firefox. The relevant Firefox bug is now fixed.

Starting to understand this issue.
Current status:

1. Line by line navigation is mostly fixed in all browsers but it is still depending on type of edit field what a line is and how the cursor is moved when using up and down arrow keys. No specific issue here.
2. Paragraph navigation is fixed in every edit field with the new setting in document navigation category of NVDA, letting NVDA to define one or more line breaks as indication of a new paragraph
3. Navigation by page or screen with page up and page down, or home / end, this cannot be fixed in the browsers since the cursor moves vertically and not at the beginning of the line, so the navigation migh result in repetitions if there is no equivalent vertical position to move to. For this NVDA would need it own routine, as it provides for paragraph navigation.
4. Word by word navigation: NVDA would need its own routine, actually I can reproduce it in all browsers. Related issues are The word before PERIOD is announced twice in power point 2013 placeholder when navigatin #3971 and Ignore punctuation level when moving by word or greater, and the new caret location starts on punctuation #8057:

• In Chromium browsers with focus mode, NVDA repeats the punctuations before the line break character while in Firefox the punctuations are not recognized as words in the ctrl+left and right arro. navigation, so NVDA repeats the words before punctuation.
• In all browsers, line feed character is not recognized as word itself in focus mode, so NVDA repeats the word / the punctuation before the line feed character.
• In browse mode though, NVDA recognizes line break characters as single words in the words navigation but not the punctuation.
  Str:

1. Copy the text below into the comment edit filed of this issue
2. navigate with ctrl+arrow keys from the beginning to the end, in focus and browse mode.

Actual:

• NVDA repeats words or punctuations when there are line breaks added in focus mode while using word navigation
• NVDA ignores punctuation in browse mode when using word navigation.

Expected:

• NVDA should treat line break characters in focus mode, and punctuations / symbols in browse and focus mode, as single words
• This behavior should be the default, changing the current symbol / punctuation level should not affect word navigation.
• one or more Space and white space characters next to each other should be sumarized and treated as a single word "blank"

"Hello,
How are you?

Fine

And you?

"

So I would restrict this issue for word by word navigation in general, since text navigation in focus mode with page up and down, home or end is not common in browsers.

If we restrict this issue to word by word navigation, then we could close this in favor of #8057.

cc: @jcsteh what do you think?

So I would restrict this issue for word by word navigation in general, since text navigation in focus mode with page up and down, home or end is not common in browsers.

Maybe it's less common but it remains a bug. There is no reason to close; it may just be considered lower priority if it is less common.

Personally, I am using word by word nav, but also home/end.
I do not usually use pgUp or pgDown in focus mode, but maybe others do, e.g. people using web apps such as editors.

1. Line by line navigation is mostly fixed in all browsers but it is still depending on type of edit field what a line is and how the cursor is moved when using up and down arrow keys. No specific issue here.

There is still an issue in both Chrome and Firefox where if you're positioned at the end of a wrapped line, NVDA will report the next line instead of the current line. STR:

1. Open this test case:
   data:text/html,<textarea cols="2">ab cd
2. Focus the text box.
3. Press control+home.
4. Press end.
   • Expected: NVDA should say "blank"
   • Actual: NVDA says "c"
5. Read the current line (desktop: NVDA+upArrow, laptop: NVDA+l).
   • Expected: NVDA should say "ab "
   • Actual: NVDA says "cd"

Firefox at least supports the necessary IAccessible2 stuff to make this work correctly, but NVDA doesn't support it yet. I don't think Chrome does, but I'm not sure.

4. Word by word navigation: NVDA would need its own routine, actually I can reproduce it in all browsers.

I don't think this is correct. Different browsers have slightly different word navigation behaviour. That's not something NVDA should try to change. That said, the browse mode behaviour is not going to be consistent with focus mode word navigation and I don't think that's important.

* In Chromium browsers with focus mode, NVDA repeats the punctuations before the line break character while in Firefox the punctuations are not recognized as words in the ctrl+left and right arro. navigation, so NVDA repeats the words before punctuation.

I'm not sure what you mean about Firefox repeating punctuation here. Can you provide a smaller example demonstrating it?

* In all browsers, line feed character is not recognized as word itself in focus mode, so NVDA repeats the word / the punctuation before the line feed character.

It looks like Firefox treats the line feed character as a separate word for control+rightArrow, but Firefox accessibility doesn't treat the line feed as a separate word. That smells like a Firefox accessibility bug to me, though I need to dig a little further.

It looks like Chrome has the same bug. Terrific.

* In browse mode though, NVDA recognizes line break characters as single words in the words navigation but not the punctuation.

I don't see why this is a bug. It's a different choice, yes, but there's no clear rule that line feeds should be treated as words.

I'm not sure what you mean about Firefox repeating punctuation here. Can you provide a smaller example demonstrating it?
Sorry I meant Firefox does not report punctuation in word by word navigation, in focus mode , only Chromium browsers do. And still they do it only if there is one punctuation sign. If there are 3 signs such as 3 question marks consecutively, they are sumarized as one word in the word navigation but NVDA does not report anything.
In contrast, Firefox just skips the signs and repeats the word when the carret lands on a line break and it actually treats the word and the punctuation signs as if they were one word all together. Take for example this:

Hello?


World???


Yes...

Actual: with ctrl+right arrow, in focus mode, NVDA repeats "hello", "world" and "yes" every time the carret lands on a line break.
Expected: NVDA should treat the punctuation and the linebreak as single words when pressing ctrl+right arrow, so the words are not repeated.
(i.e. NVDA should say on every ctrl+right arrow press:
"Hello, question mark, line feed, line feed, line feed, world, question mark, question mark, question mark, line feed"
and so on.

Just to clarify, do you have punctuation set to all? If you don't, you won't necessarily hear punctuation when moving by word.

In Firefox release, control+rightArrow in Firefox doesn't stop on punctuation at the end of words. It only stops on line feeds. That is intentional. As noted above, there's definitely a bug with accessibility reporting the wrong word for line feeds though.

There's an additional bug in Firefox Nightly related to punctuation; see https://bugzilla.mozilla.org/show_bug.cgi?id=1848282. That bug doesn't exist in Firefox release, though, and the related change won't ship to beta or release until this is sorted out. For now, if you're using Nightly, you can disable the problematic feature by setting intl.icu4x.segmenter.enabled to false in about:config.

Just to clarify, do you have punctuation set to all? If you don't, you won't necessarily hear punctuation when moving by word.

no my punctuation is set to "some", but actually the punctuation setting should not affect character and word navigation. Actually the expected behavior for punctuation setting is to affect only navigation styles greater than word navigation.

In Firefox release, control+rightArrow in Firefox doesn't stop on punctuation at the end of words. It only stops on line feeds. That is intentional.

what is the reason behind this?

you can disable the problematic feature by setting intl.icu4x.segmenter.enabled to false in about:config.

Thanks very much for this hint.

Different browsers have slightly different word navigation behaviour. That's not something NVDA should try to change. That said, the browse mode behaviour is not going to be consistent with focus mode word navigation and I don't think that's important.

Gotcha. Though I think at least in focus mode it might be worthy to find a routine that makes word navigation more consistent in edit fields in general. This does not affect only browsers, but all kinds of editors. The same problem we had for paragraphs which is now solved internally in NVDA core.

no my punctuation is set to "some", but actually the punctuation setting should not affect character and word navigation. Actually the expected behavior for punctuation setting is to affect only navigation styles greater than word navigation.

No, this assertion is not true.
Today, punctuation level does not affect character but affects all other types of navigation (word, line, paragraphe, etc.)

There are related discussions on this topic however in #8057 #10855 and #11779 .

actually the punctuation setting should not affect character and word navigation. Actually the expected behavior for punctuation setting is to affect only navigation styles greater than word navigation.

That is only true if the chunk is a single character, since otherwise, you'd hear silence. For anything larger, the punctuation level applies.

In Firefox release, control+rightArrow in Firefox doesn't stop on punctuation at the end of words. It only stops on line feeds. That is intentional.

what is the reason behind this?

This was probably modelled on the way Windows standard Edit controls work. For example, if you open the Run dialog and type there, you'll notice that control+rightArrow doesn't stop on punctuation at the end of a word there either. Unfortunately, Microsoft have been pretty inconsistent since then. Newer text boxes (not standard Edit controls) seem to implement word navigation very differently.

I think at least in focus mode it might be worthy to find a routine that makes word navigation more consistent in edit fields in general. This does not affect only browsers, but all kinds of editors. The same problem we had for paragraphs which is now solved internally in NVDA core.

I disagree. The screen reader should be making as few modifications as possible to the user experience of the app. Altering that too much is asking for confusion and incompatibility. Paragraphs might have been a reasonable exception because this simply isn't supported in many controls at all. In contrast, word navigation is supported across the board. Aside from anything else, trying to enforce consistent word navigation is likely to cause a pretty severe performance hit, especially for something like word navigation where one may want to move very fast.