Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate feedback whilst reading edit fields in Firefox #5115

Closed
nvaccessAuto opened this issue May 28, 2015 · 12 comments
Closed

Duplicate feedback whilst reading edit fields in Firefox #5115

nvaccessAuto opened this issue May 28, 2015 · 12 comments

Comments

@nvaccessAuto
Copy link

Reported by elliott94 on 2015-05-28 18:55
From memory I believe that this particular issue may have been reported several years ago, but I've been unable to find any relevant information.

Whilst using Firefox 38.0.1 in combination with the latest NVDA snapshot (Next 12021,7c7aad1), I've noticed that whilst editing form content in Focus Mode duplicate information is presented. There doesn't seem to be a set of conditions where this behaviour can be observed; whilst moving the focus to the next/previous line or character the previous information for the relevant line or character is given. I've noticed this on multiple machines running Windows 7 Home Premium X64.

@nvaccessAuto
Copy link
Author

Comment 1 by elliott94 on 2015-05-28 18:56
Changes:
Changed title from "Duplicate feedback whilst editing form content in Focus Mode" to "Duplicate feedback whilst editing form content in Focus Mode in Firefox"

@nvaccessAuto
Copy link
Author

Comment 2 by jteh on 2015-05-29 00:00
I assume you still have video acceleration disabled given #5033? Poor performance would definitely cause this issue. If it were just related to being at the end of a line, that could be #3156.

@nvaccessAuto
Copy link
Author

Comment 3 by elliott94 (in reply to comment 2) on 2015-05-29 18:51
Replying to jteh:

I assume you still have video acceleration disabled given #5033? Poor performance would definitely cause this issue.

I do still have this setting disabled - general performance returned to normal after disabling this particular setting.

If it were just related to being at the end of a line, that could be #3156.

I think the behaviour outlined in #3156 mirrors the experience that I'm having. I'll close this as a duplicate for now, but will reopen this ticket if I have any more information.
Changes:
Added labels: duplicate
State: closed

@nvaccessAuto
Copy link
Author

Comment 4 by elliott94 on 2015-10-11 20:33
I'm reopening this ticket after observing further behaviour - outlined below.

Whilst at first it appeared that this only occurred whilst using the cursor keys to navigate text within a form entry field, I've now noticed this whilst in the Search field (Ctrl+K) of Firefox. Furthermore, this behaviour can be seen when not focused at the end of a line, i.e. when simply cursoring down through an edit field. It's important to note that this only happens within edit fields - either in a multiline (such as can be found within Trac), or as previously mentioned in Firefox's Search entry box.
Changes:
Changed title from "Duplicate feedback whilst editing form content in Focus Mode in Firefox" to "Duplicate feedback whilst reading edit fields in Firefox"
Removed labels: duplicate
State: reopened

@nvaccessAuto
Copy link
Author

Comment 5 by jteh on 2015-10-16 04:14
There are two distinct issues here and I want to make sure we keep them separated. I'll provide a way to detect each case.

  1. Duplicate/incorrect reading when the cursor is at the end of a line. That's firefox edit fields: duplicate llines and words #3156. Note that you can end up at the end of a line without intentionally doing this; e.g. if you move to a line which is shorter than the line you were previously on. When this occurs, pressing NVDA+upArrow to read the current line (laptop: NVDA+l) will still report the incorrect line.
  2. Duplicate reading when not at the end of a line. This probably occurs because the cursor took a while to move and NVDA timed out, believing the cursor wasn't going to move. When this occurs, pressing NVDA+upArrow/nvda+l will read the correct line, even though upArrow/downArrow reported incorrectly.

You appear to be reporting the second issue, but it'd be great if you could verify the behaviour I explained.

If that is indeed the case, the question is whether you see this with NVDA 2015.3, NVDA master or only with NVDA next. If only in NVDA next, it could be due to #1668, but we'll need to troubleshoot further to isolate that.

Thanks.

@nvaccessAuto
Copy link
Author

Comment 6 by elliott94 (in reply to comment 5) on 2015-10-16 06:33
Replying to jteh:

There are two distinct issues here and I want to make sure we keep them separated. I'll provide a way to detect each case.

  1. Duplicate/incorrect reading when the cursor is at the end of a line. That's firefox edit fields: duplicate llines and words #3156. Note that you can end up at the end of a line without intentionally doing this; e.g. if you move to a line which is shorter than the line you were previously on. When this occurs, pressing NVDA+upArrow to read the current line (laptop: NVDA+l) will still report the incorrect line.
  2. Duplicate reading when not at the end of a line. This probably occurs because the cursor took a while to move and NVDA timed out, believing the cursor wasn't going to move. When this occurs, pressing NVDA+upArrow/nvda+l will read the correct line, even though upArrow/downArrow reported incorrectly.

You appear to be reporting the second issue, but it'd be great if you could verify the behaviour I explained.

You're right - this is in relation to the second case. That said, this behaviour was definitely occurring before any code on this was merged a couple of weeks ago; I've been experiencing the same issue before opening this ticket earlier in the year, but hadn't thought to open it sooner.

If that is indeed the case, the question is whether you see this with NVDA 2015.3, NVDA master or only with NVDA next. If only in NVDA next, it could be due to #1668, but we'll need to troubleshoot further to isolate that.

Thanks.

I'm currently testing with the latest Next snapshot; I can test with other branches if that would help, but since I've been experiencing this for a while before the relevant code from #1668 was merged I'm not sure if that could be the issue.

@LeonarddeR
Copy link
Collaborator

@elliott94: Could you provide a status update for this issue?

@elliott94
Copy link

I'm afraid so - behaviour is still as described. Am I correct in thinking that this is more of a Firefox bug, though?

@Brian1Gaff
Copy link

Brian1Gaff commented Feb 18, 2018 via email

@Adriani90
Copy link
Collaborator

@elliott94 I am testing several website in Firefox 66.0.2 where such issues occured before and now I cannot reproduce it anymore. I am testing with NVDA 2019.1. Are you still seeing this issue? Thanks!

@elliott94
Copy link

Happy to close for now; I haven't seen this for a while.

@Adriani90
Copy link
Collaborator

Thanks for confirming. Just comment on it if you have this issue again and we can reopen it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants