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

Jump to bottom

Buffers not Being Completely Loaded in Some Pages When Using Recent Compilations of Chrome #4318

Closed
nvaccessAuto opened this issue Jul 19, 2014 · 8 comments
Closed

Buffers not Being Completely Loaded in Some Pages When Using Recent Compilations of Chrome #4318

nvaccessAuto opened this issue Jul 19, 2014 · 8 comments
Labels
blocked/needs-external-fix blocked bug close/worksforme feature/browse-mode GoogleWork

Comments

@nvaccessAuto
Copy link

Reported by ateu on 2014-07-19 12:59
Steps to reproduce:

  1. Using Chrome 38, ( dev or canary channel can be used) open facebook.com or the Google search page;
  2. When NVDA announces the page title, try to navigate through the page with arrow keys or using the quick navigation keys;

Expected result: The page should be completely loaded.
Current result: In most cases, just a small part of the page is loaded, and is necessary to press NVDA+f5 to refresh the buffer. For example, in Facebook, the posts aren't showed, and in google.com, the search results aren't showed.
I think this is a problem in NVDA, as I have tested using other screen readers and this doesn't occurs.
Blocking #4566, #4657, #4836
@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2014-07-20 22:09
There are quite a lot of focus and event changes underway in Chrome at the moment, so I suggest only testing with Canary for now.

I'm not sure exactly what is causing this, but there are still some remaining event related issues in Chrome that need to be addressed. Chrome now fires focus earlier, which means NVDA will now render the page earlier, but if Chrome doesn't then fire correct events (which it sometimes doesn't), the page won't get updated correctly. It's possible we render the page earlier than other screen readers. I'll need to track these cases down and file bugs for them.

@nvaccessAuto
Copy link
Author

Comment 3 by jteh on 2014-10-22 06:00
Filed GoogleIssue:chromium:425861, GoogleIssue:chromium:425864, GoogleIssue:chromium:425867, GoogleIssue:chromium:425869, GoogleIssue:chromium:425874 and GoogleIssue:chromium:425876.

@nvaccessAuto
Copy link
Author

Comment 4 by jteh on 2014-10-22 06:49
And GoogleIssue:chromium:425885.

@nvaccessAuto
Copy link
Author

Comment 9 by jteh on 2015-01-29 07:10
Most of these issues are now fixed in latest Chrome Canary except GoogleIssue:chromium:425861 and GoogleIssue:chromium:425885.

This was referenced Nov 10, 2015
Closed
Closed
Closed
@jcsteh
Copy link
Contributor

jcsteh commented Apr 25, 2017

Chromium issue 425861 was fixed some time ago. Issue 425885 is still open.

@jcsteh jcsteh added the blocked label Apr 25, 2017
@ehollig
Copy link
Collaborator

ehollig commented Nov 21, 2017

Chromium issue 425885 has been archived. Is this still an issue for users? All other Chrome issues seem to be resolved.

@Adriani90
Copy link
Collaborator

@Ateu is this still reproducible? I am using Chrome 71 and cannot reproduce this issue with NVDA 2018.4.

@Adriani90
Copy link
Collaborator

Closing as works for me. If it is still reproducible, please feel free to comment and we will reopen it. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
blocked/needs-external-fix blocked bug close/worksforme feature/browse-mode GoogleWork
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jcsteh @nvaccessAuto @ehollig @Adriani90