Closed Bug 414491 Opened 16 years ago Closed 2 years ago

Too many accessible events when typing in Firefox3 location bar

Categories

(Core :: Disability Access APIs, defect)

x86
Windows Vista
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
mozilla1.9

People

(Reporter: mick, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: access, perf, regression, Whiteboard: [bk1])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008012804 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008012804 Minefield/3.0b3pre

Due to many show/hide/reorder events being fired when typing in the Firefox3 location bar, NVDA can lock up for an amount of time. When typing one character its about 400 ms, when typing an entire address and pressing enter, it can be up to 10 seconds before NVDA can fianlly announce what is going on, and see that Firefox is going to the address in question. Users of Jaws apparently also can experience some performance issues in this situation. Also Orca can get a bit laggy after typing in characters as well.
In theory it could be said that screen readers should employ logic to ignore particular events in particular situations, however, there is really no other major applications or operating system situations, including with in Firefox3 where this over amount of events occures. So, an idea might be to find out what all of these events are, and possibly cut down on many of the events that the screen readers may not actually need to know about.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox3
2. Open Accessibility Probe, move to the event view and set it up to watch for all show/hide/reorder events
3. Tell accessibility probe to start tracking events 
4. move to the Firefox3 location bar and type in some characters 
5. move back to accessibility probe and note the events tracked
Actual Results:  
Many events are listed, possibly more than 300 or so

Expected Results:  
Possibly not *so* many?

At very least it should be investigated to see exactly what these events are, and why they occure, so that screen readers can either ignore them or handle them better. However the better option would still be to massivly cut down on all events in this situation. 
Note also that although Jaws and Window Eyes probably track these events in-process, NVDA and Orca are out-of-process and  processing any one of these events is not trivial as far as performance goes.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012704 Minefield/3.0b3pre
This also occurs for me with JAWS 9.0.552. The issue is not as pronounced as in NVDA, but it is still noticeable. The easiest way to observe this problem using JAWS is to set typing echo to characters and then observe the lag while typing into the address bar.
Keywords: access, perf, regression
Blocks: fox3access
Hi Seth.

For each character I type I get one set of these for each item in the list:

[Show description ]
[Show hbox ]
[Show hbox ]
[Show label ]
[Show image ]
[Show hbox ]
[Show spacer ]
[Show text node ]
[Show text node ]
[Show span ]

I think there's also 1 or 2 node removals and insertions for each item, in order to do the bold/underline effect.

Is CSS visibility being used? That can cause us to get notifications for every item in a subtree, which is obviously slow. We have to coalesce those to remove redundant events.
Requesting that this be looked at for after FF3 B4. This could possibly be in conjunction with bug 418845, since they may be related (both dealing with listitems and repopulating lists based on changges in a different widget).
Priority: -- → P1
Target Milestone: --- → mozilla1.9
Jamie, Mick, is this still an issue for you? I'm using Firefox daily with NVDA and use the AwesomeBar extensively, and have not seen hangs for months. Can this be closed as worksforme?
I still find response to be extremely sluggish, especially when there are a lot of autocomplete matches for a given string. The best way to "feel" this is to enable "Speak typed characters" (press NVDA+2) and try typing "http" or something equally common.
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Ping. This is still an issue, and given the fact that almost everyone would use the location bar regularly, I think it is important for it to be snappy for a11y.
Yeah we're firing too many events generally and are looking to rework some of our eventing code. I hope to start this larger work soon.
Severity: normal → major
Blair, we briefly discussed this at our meetup. Do you have plans to make the dom changes more atomic?
I don't have any specific/concrete plans for it, no. It was more of a brain dump :)

From what I can tell, this will happen with any autocomplete textbox that uses richlistitems. 

I believe that the code that's doing some of this (parts of _adjustAcItem() in toolkit/content/widgets/autocomplete.xml) can be replaced by CSS. That would get rid of some (maybe half?) of the events *in some cases*.

Unfortunately, for the majority of cases, items in the dropdown are reused (for performance reasons) - which I assume means the above tweak wouldn't reduce the number of events. So basically, it may require removing a substantial performance feature of all autocomplete textboxes, in order to make it more atomic.

Someone more familiar with that autocomplete code should look into this - hopefully I'm missing something and the fix will be something far less drastic.
Ugh. Okay thanks for the update. I'd like to fix this without hurting perf anywhere. This fix might belong in autocomplete, or it might belong in our accessibility event logic, or ... will dig later if no one else jumps in.
Status: UNCONFIRMED → NEW
Ever confirmed: true
That's no core accessibility issue I think. Now it sounds we do all smart things we can. For example, when I type 'a' character into awesome bar then amazon.com suggestion appear and we fire one text inserted event with "http://amazon.de" text and five show events for "http://www.", "a", "m", "a" and "zone.com".

Events amount can be reduced if all changes happen until DOM is attached to tree or while the list item has display none.

Though I bet we can do some hacks on a11y side like fire show event on parent as it was shown. But in general we could try to add IA2 to add some context information for reorder events and get rid show/hide events at all, they unperformant as the fact of their existing.
(In reply to comment #12)
> That's no core accessibility issue I think. Now it sounds we do all smart
> things we can.
Has this improved recently? If so, it's probably worth re-testing with an AT.
> For example, when I type 'a' character into awesome bar then
> amazon.com suggestion appear and we fire one text inserted event with
> "http://amazon.de" text and five show events for "http://www.", "a", "m", "a"
> and "zone.com".
Do you actually see all of these results visually? If not, they probably shouldn't fire events (but this isn't a core a11y issue, as you say).

> But in general we could try to add IA2 to add some context
> information for reorder events
It's not possible to add context to MSAA/IA2 win events without breaking support for out-of-process clients. This is because win events can't pass arguments, so the only way to provide context is to implement properties on the object, which can only be guaranteed to be correct for a given event if that event is handled synchronously, which is only possible in-process. An example of this is IAccessibleText::newText/oldText, which is useless out-of-process. The only solution to this problem is to invent an entirely new event framework.
(In reply to comment #13)

> Do you actually see all of these results visually? If not, they probably
> shouldn't fire events (but this isn't a core a11y issue, as you say).

I think I could if I would be a fly :) It's quick enough for sighted users but lot of a11y events is slow.

> > But in general we could try to add IA2 to add some context
> > information for reorder events
> It's not possible to add context to MSAA/IA2 win events without breaking
> support for out-of-process clients. This is because win events can't pass
> arguments, so the only way to provide context is to implement properties on the
> object, which can only be guaranteed to be correct for a given event if that
> event is handled synchronously, which is only possible in-process. An example
> of this is IAccessibleText::newText/oldText, which is useless out-of-process.
> The only solution to this problem is to invent an entirely new event framework.

yep, I kept in mind in-process processing. Any thoughts for entirely new event framework? I'm far from Windows APIs and don't have any ideas on this.
(In reply to comment #14)
> Any thoughts for entirely new event
> framework? I'm far from Windows APIs and don't have any ideas on this.
I guess COM events make some sense as a replacement (since we're dealing with COM objects). However, like all things COM, they're not particularly lightweight and get pretty nasty when there are a lot of events. (At least with win events, we can do some filtering on the hwnd/objID/childID and drop the event entirely if we choose to.) This is probably a discussion that needs to be had elsewhere, as it goes alongside creating a new API.
Sure. Could you please start a thread on IA2 list?
I suspect event coalesence has improved things here but someone from AT world needs to confirm.

Jamie?
Whiteboard: [bk1]
If I type http://www.google.com/ into my Location bar, I get over 500 show/hide/reorder events. It's possible that a few of these were from elsewhere, but the vast majority were related to the Location bar.
Removing P1 status since it hasn't received commensurate action according to https://wiki.mozilla.org/Bugmasters/Process/Triage
Priority: P1 → --
A pretty old issue, curious whether the awesome bar still experiences the problem.

Hi James,
Could you please check if this issue is still reproducible on the latest Firefox version? I tried to look around for how to get started with Accessibility Probe but couldn't find the needed info about it.

Flags: needinfo?(jteh)

I do see some slight lag when typing fast in the address bar with speak typed characters enabled in the NVDA screen reader. However, it is very slight and nothing like it was when this was reported. I didn't look ta event logs, just at the user impact with NVDA. I suspect a combination of things have resulted in improvements here: event coalescence in Gecko a11y, the switch to the new Quantumbar implementation, maybe changes in NVDA.

Given that I can't reproduce a real problem here and we haven't any user complaints about this for a long time, I'm closing this. We can always reopen if users are still experiencing problems here.

Flags: needinfo?(jteh)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.