1342243 - Firefox hangs when navigating through aria-autocomplete list with a screenreader

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect, P1)

Description

[u554753]

JAWS Version: 18.0.2530
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0

Steps to Reproduce:
1. Open Jaws or equivalent screenreader
2. Navigate to http://oaa-accessibility.org/example/11/
3. Attempt to select a state from the drop-down menu

Expected Result:
Screenreader reads the content of the selection, user can navigate through the page.

Actual Result:
Firefox hangs and becomes unresponsive

Comment 1

[alexander :surkov (:asurkov)]

is there a perf profile by a chance?

Comment 2

[Marco Zehe (:MarcoZ)]

I cannot reproduce with current Nightly build 2017-02-23 and the latest NVDA Next snapshot. E10S is on, and no matter if I just arrow up or down in the list of states, or press Alt+DownArrow, or Enter to expand the list, then arrow up and down, then press Enter to select the new state, I get no hang. So this is something specific to JAWS, it seems.

Comment 3

[:Gijs (he/him)]

Needinfo for comments 1 & 2.

Comment 4

[u554753]

Per Comment 1, can you elaborate what you mean by "perf" profile?

Comment 5

[alexander :surkov (:asurkov)]

(In reply to Grover Wimberly IV [:Grover-QA] from comment #4)
> Per Comment 1, can you elaborate what you mean by "perf" profile?

here's a step by step guide https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Comment 6

[u554753]

Oh, a performance profile. Okay, I'll follow up with one.

Comment 7

[(No longer employed by Mozilla) Aaron Klotz]

Grover, have you had a chance to obtain a perf profile for this?

Comment 8

[u554753]

https://cleopatra.io/#report=5a439d241a261756d6ebd1fe09bad03073b2a133

Comment 9

[alexander :surkov (:asurkov)]

I see the most time is spent in NtUserNotifyWinEvent, i.e. on event's delivering when we process mutation events.

Comment 10

[Jim Mathies [:jimm]]

David, this is a P1, and I'm wondering if it's e10s related. PI is currently tracking this as a blocker, could you help me figure out if that's the case?

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

Marco might beat me... I left my windows machine at work.

Comment 12

[Marco Zehe (:MarcoZ)]

I am currently out of business on nightly builds due to bug 1395840, and don't expect to be back in business before this is fixed. Besides, I have had no luck in trying to obtain profiles, this is not a very accessible thing to do when you're blind.

Comment 13

[David Bolter [:davidb] (NeedInfo me for attention)]

I just realized this came back to me sorry. I think Jim's question is whether this is e10s related (and therefore blocking windows e10s a11y)? So we need to compare e10s and non e10s... which probably doesn't need a profile to answer. Alex you made this a dependency of 1368784, did you try the STR in non-e10s mode?

Comment 14

[alexander :surkov (:asurkov)]

I think the dependency has been added based on the profile (comment #6). The profile says that most of the time is spent on events delivering, so if reduced the amount of events sent to AT, then it'd be a fix. I suppose that e10s is worse than non e10s builds, but I wouldn't say this is e10s specific problem.

Comment 15

[u554753]

Come back and check if this is e10s specific

Comment 16

[u554753]

This issue seems to be related to the JAWS hangs that we're tracking in Bug 1388409. I am not seeing this consistently and it would probably be best to record any future issues with it on that bug.