New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 861567 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 12
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-08-01
OS: Mac
Pri: 1
Type: Bug
Team-Accessibility



Sign in to add a comment

A11Y: Chrome always "busy" and unusable for VoiceOver users with new Gmail

Project Member Reported by markcar...@google.com, Jul 8

Issue description

This is reproduceable on latest Chrome Canary, Beta and Stable on latest Mac Os 10.13.X and 10.14 beta.
With VoiceOver enabled and Zoom enabled using the New Gmail UX, Chrome says busy 10 times a minute. 
Similiar experience although less severe with Google Calendar. 
This performance issue makes using Gmail with Chrome on Mac OS impossible for a Voice Over screen reader user.
I understand the issue may be an interaction between Gmail, Chrome and VoiceOver, but the end result is just broken. 

Note that testing with other browsers like safari show much more reduced "Busy" with Gmail, and testing with other Web Mail systems and Chrome has shown better experience as well, so this issue seems to be Chrome together with Gmail.

This makes it impossible for me to use Chrome and Gmail.
 
Labels: -CrOSFilesCategory-Accessibility
NextAction: 2018-08-01
Owner: ellyjo...@chromium.org
Status: Assigned (was: Untriaged)
I can't reproduce the constant "busy" but I think I see the same issue - there is noticeable UI latency when navigating gmail using VoiceOver, even on my macpro workstation. This problem has been around for quite a while :( I'll try to scrape up some time to look at it.
Owner: dmazz...@chromium.org
I've been profiling Chrome with the new Gmail and I think I found the bottleneck. I'll upload a change shortly.

Project Member

Comment 3 by bugdroid1@chromium.org, Jul 11

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/efe0b6cf34074c3deef387e2d4e222797e38d407

commit efe0b6cf34074c3deef387e2d4e222797e38d407
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Wed Jul 11 01:26:52 2018

AXNodeObject::ChildrenChanged shouldn't invalidate all ancestors.

This bug has been around since WebKit. When AXNodeObject::ChildrenChanged() is
called, it invalidates the list of children of the current node (correct), but it
also does so for all ancestors. This is wasteful and I've recently discovered
that this is a significant performance bottleneck on sites like the new Gmail
when composing a message; every character typed ends up forcing us to explore
nearly the whole tree, rather than only the part that changed.

However, just invalidating the current node isn't quite enough if that node is
ignored. When an AXObject computes its children, if any child is marked as
"ignored" it recursively adds the children of that ignored child. Thus if an
ignored node's children are invalidated, we need to walk up to an unignored
ancestor and ensure that it recomputes its children, too.

It's likely that this reason (handling ignored nodes properly) is why
the bug persisted in WebKit. Also the way WebKit is architected,
the performance impact is not as large there.

This is well-covered by existing tests. Dozens of tests fail if we
fail to invalidate nodes whose children have changed (whereas
invalidating too much just silently wastes resources).

Bug:  861567 
Change-Id: Ib9688615027ea5f7d4a01f74c830d2ae381fcf63
Reviewed-on: https://chromium-review.googlesource.com/1130996
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Alice Boxhall <aboxhall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574030}
[modify] https://crrev.com/efe0b6cf34074c3deef387e2d4e222797e38d407/third_party/blink/renderer/modules/accessibility/ax_node_object.cc
[modify] https://crrev.com/efe0b6cf34074c3deef387e2d4e222797e38d407/third_party/blink/renderer/modules/accessibility/ax_object.cc

It looks like a big issue here is with AXPosition's less-than operator. Calling GetParentPosition on a text position is quite expensive, especially to do that all the way up the parent chain.

Project Member

Comment 5 by bugdroid1@chromium.org, Jul 12

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/adeaf13d9c8651fcf83c9e5a6a7d1173f1eb27e1

commit adeaf13d9c8651fcf83c9e5a6a7d1173f1eb27e1
Author: Nektarios Paisios <nektar@chromium.org>
Date: Thu Jul 12 20:01:52 2018

Improved performance of AXPosition::operator less than

Only move up or down the tree using text equivalent positions (by calling CreateParentPosition and AsLeafTextPosition) when we absolutely need to.
R=dmazzoni@chromium.org

Tested: VoiceOver on Mac by navigating in Gmail and checking how many times you hear "Busy"
Change-Id: Id9469e52ef87b8b8a0c6c5fac5325abec415382d
Bug:  861567 
Reviewed-on: https://chromium-review.googlesource.com/1133334
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574689}
[modify] https://crrev.com/adeaf13d9c8651fcf83c9e5a6a7d1173f1eb27e1/ui/accessibility/ax_node_position_unittest.cc
[modify] https://crrev.com/adeaf13d9c8651fcf83c9e5a6a7d1173f1eb27e1/ui/accessibility/ax_position.h

Status: Fixed (was: Assigned)
AXPosition operator less than has just been dramatically improved. I'll mark this fixed and if anyone is still seeing issues, please let us know.
The NextAction date has arrived: 2018-08-01

Sign in to add a comment