search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.12k stars 637 forks source link

firefox edit fields: duplicate llines and words #3156

Closed nvaccessAuto closed 4 months ago

nvaccessAuto commented 11 years ago

Reported by camlorn on 2013-04-15 15:15 In Firefox 20.0.1 and NVDA main-5986: When editing in edit fields, NVDA is sometimes deciding that lines are to be duplicated. Specifically, it will sometimes read the previous line again instead of the next line. If there is a post with four lines, it may sometimes read line 1 twice followed by line 3 twice, skipping 2 and 4 entirely. This is consistent, that is, it will always misread and skip the same lines, and when it starts it will always do it in pairs. It will also sometimes decide that, when moving by word, the first word of a line is the last word of the previous line, and seems to do so at the same times. I've observed this very rarely in the NVDA ticket submission edit field. It's common on audiogames.net forums and mudconnect.com forums, shows up on topmudsites.com forums, just to name a few, but can happen in any multiline edit field. Moving by character seems to be unaffected, and selecting the text will report the correct lines and words. This seems to be becoming more common for me. Just as an additional piece of information, jaws 13 does this as well (it may be fixed in jaws; I've not used jaws for any significant period of time for about 2 months now).

nvaccessAuto commented 11 years ago

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.

nvaccessAuto commented 11 years ago

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.

nvaccessAuto commented 11 years ago

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"

nvaccessAuto commented 11 years ago

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.

nvaccessAuto commented 11 years ago

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.

nvaccessAuto commented 11 years ago

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

nvaccessAuto commented 11 years ago

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.

nvaccessAuto commented 11 years ago

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?

Adriani90 commented 5 years ago

@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.

jcsteh commented 5 years ago

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

Adriani90 commented 1 year ago

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 #3971 and #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:
  5. Copy the text below into the comment edit filed of this issue
  6. navigate with ctrl+arrow keys from the beginning to the end, in focus and browse mode.

Actual:

Expected:

"Hello, How are you?

Fine

And you?

"

Adriani90 commented 1 year ago

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?

CyrilleB79 commented 1 year ago

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.

XLTechie commented 1 year ago

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.

Same for me. I use home/end all the time in text fields and textareas.

jcsteh commented 1 year ago 
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.

Adriani90 commented 1 year ago

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.
jcsteh commented 1 year ago

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.

Adriani90 commented 1 year ago

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.

Adriani90 commented 1 year ago

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.

CyrilleB79 commented 1 year ago

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 .

jcsteh commented 1 year ago

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.

CyrilleB79 commented 4 months ago

@Adriani90, @jcsteh and @camlorn, this issue is about to be closed by #16745. However some related but distinct issues have been raised in the current issue. Could you check if they are still relevant and open a dedicated issue for each of them if needed?

jcsteh commented 4 months ago
  1. I don't think that PR will fix #9305, which has been closed as a duplicate. That probably needs to be fixed in Chrome and is likely related to fetching boundaries near punctuation/line feeds in general, rather than being specific to the caret at the end of the line.
  2. In both Chrome and Firefox, a line feed isn't treated as a word by accessibility, even though moving the cursor by word stops on a line feed. That needs to be fixed in both Chrome and Firefox and again isn't specific to the caret.
  3. Word boundaries being inconsistent between apps (and inconsistent with browse mode) is IMO not a bug and not something we should try to fix, as doing so would override the behaviour of the app. What we do want is for word boundaries to be consistent in a given app for both cursor navigation and accessibility.
jcsteh commented 4 months ago

In both Chrome and Firefox, a line feed isn't treated as a word by accessibility, even though moving the cursor by word stops on a line feed.

For Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1904999

ahicks92 commented 4 months ago

(I used to be Camlorn).

@jcsteh I don't have the reference handy but VSCode opened an issue about this years ago and got no traction from Google. Try moving by word over C++ and Rust code. It's fun.

@CyrilleB79 Can you tell me what we need to check specifically, I don't even remember this issue. I also don't run betas anymore and can't build from source for some reason or other. Looking at my original comment that's actually worked fine for years now as it is.

It has been over a decade, sorry. And I'm short on time right now.

CyrilleB79 commented 4 months ago

@ahicks92 I was referring to https://github.com/nvaccess/nvda/issues/3156#issuecomment-155306270.

Is all this fixed in last alpha?

If it is fixed, or it does not matter anymore for you, just ignore this. If it is not fixed, open an issue to explain the remaining issue.

Note: when running last alpha, you may get a warning from Windows Defender; this is expected, just run anyway.