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

NVDA refuses to read text after switching between tabs in Firefox #1591

Closed
nvaccessAuto opened this issue Jun 19, 2011 · 11 comments
Closed

NVDA refuses to read text after switching between tabs in Firefox #1591

nvaccessAuto opened this issue Jun 19, 2011 · 11 comments

Comments

@nvaccessAuto
Copy link

Reported by elliott94 on 2011-06-19 19:03
I've experienced this several times now, but have only figured out what causes it to occur. I'm unsure at this time whether it's an NVDA or Firefox bug, but thought it'd be best to create a ticket in either case. Currently running snap 4338, so apoligies if anything has been fixed between this and 4475.

Here's how to reproduce. I've used Google in this example, but the same behaviour can be seen when entering data into any text form. I'm running Firefox 4, so am not sure if this is present in Firefox 3.6.X (although I never saw it)

  1. Open the Google website, and activate Focus Moad.
  2. Type some text into the Search text field.
  3. While still in Focus Moad, press CTRL-T to open a new tab.
  4. Close this tab by using CTRL-W.

Expected results: NVDA should return focus to the previous document, and read text as normal.

Actual result: when using any combination of the arrow keys to read text, no speech feedback is given, and the only way to return focus is to Alt-Tab back to the window.

@nvaccessAuto
Copy link
Author

Comment 1 by briang1 on 2011-06-19 21:06
Well you are using windows 7, I tried this in XP out of interest, and do not get the effect at all, at least the three times I tried it just now.
Are you running on a 64 bit version of Windows? Maybe this might have some bearing.

The blank tab opened here says about when its opened, for some reason.

Does it always happen, or is it intermittent?

@nvaccessAuto
Copy link
Author

Comment 2 by kevinchao89 (in reply to comment 1) on 2011-06-19 21:16
Windows 7 64-bit, Firefox 6 Nightly 7.0a1 (2011-06-19), NVDA Snapshot 4475
This bug is confirmed exactly as described. 100% reproducible.

@nvaccessAuto
Copy link
Author

Comment 3 by briang1 on 2011-06-19 21:49
I think this is related to a previously raised ticket about virtual buffers not being created in 64 bit versions of FF. Have a try with one snap backwards, ie 72 and see if it does it there.
Read the changelogs if its the same as what I suspect it to be.

@nvaccessAuto
Copy link
Author

Comment 4 by mdcurran on 2011-06-19 23:07
I can reproduce on Windows 7 64 bit, firefox 4. Though I don't think the Operating system version would affect it.
Technical info:
Yet another case of Gecko returnning -1 for IAccessibleText::caretOffset.
Strangely though surely focus really is on the Google search edit field once closing the tab, we certainly get a focus event for it.

@nvaccessAuto
Copy link
Author

Comment 5 by jteh on 2011-06-19 23:37
I can confirm the issue as well. When it occurs, the edit field doesn't have the focused state, so focus is definitely broken as far as Gecko a11y is concerned.

Interestingly enough, if you hit ctrl+t and then tab to the document before pressing ctrl+w, things work as expected. If you hit ctrl+t, tab to the document, tab back to the location bar and then hit ctrl+w, things break. From this, we can generalise this bug: it happens if you were last in the navigation toolbar when you close the tab.

This is definitely a Mozilla bug. I'll file one soon.

@nvaccessAuto
Copy link
Author

Comment 6 by jteh on 2011-06-20 04:30
Filed MozillaBug:665412.

@nvaccessAuto
Copy link
Author

Comment 7 by briang1 on 2011-06-20 06:30
Just to clarify then, is this bug only on 64 bit Win 7? I ask as I tried this a lot in XP with no problems no matter how I do it.

Maybe I'm lucky in having a slow machine!

@nvaccessAuto
Copy link
Author

Comment 8 by briang1 on 2011-06-27 11:14
Since I eventually did get this to happen, I thought I'd best let you all know. It only happens for me with alt/left to get to previous page. The way I get around it is to simply bring up and cancel the file menu with alt etc.
It ten gets created.
Those paying attention may be struck by the remakable similarity between this in FF4 and 5, and the no buffers on html in IE bug I encounter often with IE8 and XP. I suspect the cure being similar is because one is forcing nvda to see the screen anew.

It is irritating though, and as it works fine in 3.6.18, I guess its either a far to fast event for nvda to see it, or a bug in their code.

@nvaccessAuto
Copy link
Author

Comment 9 by jteh (in reply to comment 8) on 2011-06-28 02:52
Replying to briang1:

It only happens for me with alt/left to get to previous page. The way I get around it is to simply bring up and cancel the file menu with alt etc.

That's a different bug: MozillaBug:644452.

@nvaccessAuto
Copy link
Author

Comment 10 by jteh on 2011-06-28 02:57
Btw, Brian, this has nothing to do with buffer creation. It relates to navigation within an editable text field with focus mode enabled.

@nvaccessAuto
Copy link
Author

Comment 11 by elliott94 on 2012-05-28 21:32
Fixed in Firefox 10.01.
Changes:
State: closed

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

1 participant