Google Chrome 100: NVDA no longer reads the title of the newly loaded page and automatic SayAll is broken

[amirsol81]

Google Chrome 100, and presumably MS Edge 100 which hasn't been released at the time of this issue creation, has broken some aspects of NVDA's browsing capabilities and features, resulting in the suppression of the announcement of the page title upon load, and malfunctioning of the Automatic SayAll on Page Load feature. This also tampers with the capabilities of some add-ons -- namely BrowserNav.

Steps to reproduce:

While the issues mentioned here can be duplicated with all websites, this is just one sample selected for ease of duplication:

1. With Chrome 100, go to https://osara.reaperaccessibility.com

Actual behavior:

NVDA just says: "Document." Moreover, if NVDA's Automatic SayAll on Page Load check box is checked, it doesn't work and NVDA remains silent. And if, I mean only if the BrowserNav add-on is enabled, moving around with Up/Down results in the second readout of many HTML elements such as links, buttons, etc., and extra error messages (not included in my attached log) will be added to the log. Pressing Control+F5 resolves the add-on issue.

Expected behavior:

NVDA should read the title of the page upon page load. Moreover, if the relevant check box is checked, Automatic SayAll should be triggered.

System configuration

NVDA installed/portable/running from source:

Installed, also duplicated with portable

NVDA version:

2021.3.5, 2022.1 Beta 2, and Alpha 25159

Windows version:

Windows 11 Pro 64-Bit, 21 H2,

Name and version of other software in use when reproducing the issue:

Google Chrome 100 official

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

mentioned above: the latest alpha/official/beta release

If NVDA add-ons are disabled, is your problem still occurring?

Yes. However, with the BrowserNav add-on, more issues will be encountered -- the add-on won't detect its bookmarks and Up/Down will add a second readout of many HTML elements unless Control+F5 is pressed to refresh the page.

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Not tried
Log.txt

[PeterLecky]

This happens also with brave based on chromium 100.
Bigger pages are not loaded at all. E.g.:
Steps to reproduce:

1. open this page:
   https://developer.android.com/reference/android/content/Intent
2. Start to jump by headings after short time. There will be some headings but after few more seconds, the page wil disappear and you will see only cookies confirmation block in virtual buffer.

[mzanm]

Issue is also with Edge 100.

[michaelDCurran]

It seems that in Chromium 100 there is a definite change to the events we receive when a page loads.
It looks like the following happens:

1. the user causes a page to load by pressing enter in the location bar or activating a link
2. A new document accessible is created with no name, no value, and states of focused, focusable and readonly.
3. a focus event is fired on this document.
   3.1. NVDA receives the focus event, and tries to load a virtualBuffer for the document, but it is blank (no content) and NVDA cannot get its URL (documentConstantIdentifier) as the document's accValue is empty still.
4. Content starts to load, and the name, value, and descendants are added.
5. A documentLoadComplete event is fired on the document.
   6.1. Currently NVDA does not pay attention to this event, as it expects that the first or another focus event would happen when most if not all of the document was loaded.

Previously, focus was not fired on the document until the name, value, and at least some of the descendants were loaded. And therefore, NVDA was able to load a virtualBuffer with at least some content.

I am currently looking at a fix for NVDA 2022.1 which will make use of documentLoadComplete if previous tries at loading the virtualBuffer yielded in a blank document.

This is related to #13570

@aleventhal Clearly something has changed in Chromium 100, around firing of initial focus event on a new document. It looks like refreshing the document does not exhibit the issue as much if at all. Can you locate the change in Chromium? And if so, was this deliberate? As I've mentioned above, I can work around this with documentLoadComplete, and perhaps we should have always done this to begin with, however there was originally no need, and we still need to maintain compatibility with older browsers.

[aleventhal]

Thanks Mick, is there a set of easy steps to repro? Or should we look at #13570 <#13570> for steps? +Daiverd ***@***.***> , can you have the analyst team bisect it so that we are sure we know what the exact cause was? It's probably something from +Joanmarie Diggs ***@***.***> related to page load events (she's back next week).

[aleventhal]

On Wed, Apr 6, 2022 at 2:41 AM Aaron Leventhal ***@***.***> wrote:

…

Thanks Mick, is there a set of easy steps to repro? Or should we look at #13570 <#13570> for steps? +Daiverd ***@***.***> , can you have the analyst team bisect it so that we are sure we know what the exact cause was? It's probably something from +Joanmarie Diggs ***@***.***> related to page load events (she's back next week). Aaron On Wed, Apr 6, 2022 at 9:46 AM Michael Curran ***@***.***> wrote: > It seems that in Chromium 100 there is a definite change to the events we > receive when a page loads. > It looks like the following happens: > > 1. the user causes a page to load by pressing enter in the location > bar or activating a link > 2. A new document accessible is created with no name, no value, and > states of focused, focusable and readonly. > 3. a focus event is fired on this document. > 3.1. NVDA receives the focus event, and tries to load a virtualBuffer > for the document, but it is blank (no content) and NVDA cannot get its URL > (documentConstantIdentifier) as the document's accValue is empty still. > 4. Content starts to load, and the name, value, and descendants are > added. > 5. A documentLoadComplete event is fired on the document. > 6.1. Currently NVDA does not pay attention to this event, as it > expects that the first or another focus event would happen when most if not > all of the document was loaded. > > Previously, focus was not fired on the document until the name, value, > and at least some of the descendants were loaded. And therefore, NVDA was > able to load a virtualBuffer with at least some content. > > I am currently looking at a fix for NVDA 2022.1 which will make use of > documentLoadComplete if previous tries at loading the virtualBuffer yielded > in a blank document. > > This is related to #13570 <#13570> > > @aleventhal <https://github.com/aleventhal> Clearly something has > changed in Chromium 100, around firing of initial focus event on a new > document. It looks like refreshing the document does not exhibit the issue > as much if at all. Can you locate the change in Chromium? And if so, was > this deliberate? As I've mentioned above, I can work around this with > documentLoadComplete, and perhaps we should have always done this to begin > with, however there was originally no need, and we still need to maintain > compatibility with older browsers. > > — > Reply to this email directly, view it on GitHub > <#13571 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAKQAZUNRTG7ZX3KVMYXUSTVDU6NVANCNFSM5SJJ4EBA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[aleventhal]

+Chung Kim ***@***.***> who will help me bisect this issue. I was able to repro this in these versions: 100.0.4896.75 (Official Build) (64-bit) (cohort: Stable Installs & Version Pins) 101.0.4951.15 (Official Build) beta (64-bit) (cohort: Beta) 102.0.4987.0 (Official Build) canary (64-bit) (cohort: Clang-64) But not in Dev: 102.0.4972.0 (Official Build) dev (64-bit) (cohort: Dev) Chung pointed out that whatever feature is causing this issue may not be included in the dev build. We will update with bisect results. Thanks, Jen

…

On Wed, Apr 6, 2022 at 7:47 AM Daiverd ***@***.***> wrote: On Wed, Apr 6, 2022 at 2:41 AM Aaron Leventhal ***@***.***> wrote: > Thanks Mick, is there a set of easy steps to repro? Or should we look at > #13570 <#13570> for steps? > +Daiverd ***@***.***> , can you have the analyst team bisect it > so that we are sure we know what the exact cause was? > It's probably something from +Joanmarie Diggs ***@***.***> related > to page load events (she's back next week). > > Aaron > > > > > On Wed, Apr 6, 2022 at 9:46 AM Michael Curran ***@***.***> > wrote: > >> It seems that in Chromium 100 there is a definite change to the events >> we receive when a page loads. >> It looks like the following happens: >> >> 1. the user causes a page to load by pressing enter in the location >> bar or activating a link >> 2. A new document accessible is created with no name, no value, and >> states of focused, focusable and readonly. >> 3. a focus event is fired on this document. >> 3.1. NVDA receives the focus event, and tries to load a >> virtualBuffer for the document, but it is blank (no content) and NVDA >> cannot get its URL (documentConstantIdentifier) as the document's accValue >> is empty still. >> 4. Content starts to load, and the name, value, and descendants are >> added. >> 5. A documentLoadComplete event is fired on the document. >> 6.1. Currently NVDA does not pay attention to this event, as it >> expects that the first or another focus event would happen when most if not >> all of the document was loaded. >> >> Previously, focus was not fired on the document until the name, value, >> and at least some of the descendants were loaded. And therefore, NVDA was >> able to load a virtualBuffer with at least some content. >> >> I am currently looking at a fix for NVDA 2022.1 which will make use of >> documentLoadComplete if previous tries at loading the virtualBuffer yielded >> in a blank document. >> >> This is related to #13570 >> <#13570> >> >> @aleventhal <https://github.com/aleventhal> Clearly something has >> changed in Chromium 100, around firing of initial focus event on a new >> document. It looks like refreshing the document does not exhibit the issue >> as much if at all. Can you locate the change in Chromium? And if so, was >> this deliberate? As I've mentioned above, I can work around this with >> documentLoadComplete, and perhaps we should have always done this to begin >> with, however there was originally no need, and we still need to maintain >> compatibility with older browsers. >> >> — >> Reply to this email directly, view it on GitHub >> <#13571 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AAKQAZUNRTG7ZX3KVMYXUSTVDU6NVANCNFSM5SJJ4EBA> >> . >> You are receiving this because you were mentioned.Message ID: >> ***@***.***> >> >