GNOME Bugzilla – Bug 517759
Eliminate a redundancy in the label guessing for FF3 form fields
Last modified: 2008-11-12 07:02:44 UTC
We have a redundancy in our label guessing method, namely we guess: 1. From the line 2. From the table (if any) 3. From other lines Guessing from the table bails if we're not in a table (duh) OR if we're in a cell which has more than one child (the assumption being that we're potentially in a complex layout and cannot rely upon guessing by table). Therefore, we DO want to guess from other lines if we've gotten that far without success -- UNLESS we're in a table cell whose child count is one. (That's the redundancy and we'll be more performant by eliminating it).
Created attachment 105669 [details] [review] proposed patch Sample numbers: ncalls tottime percall cumtime percall 12 0.002 0.000 3.507 0.292 guessTheLabel old 12 0.003 0.000 1.689 0.141 guessTheLabel new Pylinted. Not yet regression tested. I'll do that next. In the meantime Mike please give this a spin (by itself and in combination with the combo box patch). Thanks!
This does seem to improve things while navigating. The place on bugzilla where we are still really sluggish when navigating is arrowing through the clasification list but I don't thing this and the combobox patch were intended to fix that problem.
Marking this as needs work as it didn't pass all of the regression tests. Drat! As for your observation Mike, you are correct. And to be honest, I don't think there's anything I can do to fix the problem to which you refer because I don't see anything that we're doing other than sitting and waiting for the form fields to finish populating and all those object:child-changed:add events to stop. That said... Will can you think of anything we can be doing differently in Orca to solve this problem for Mike? If there's a solution that I'm simply failing to see, please point me in its general direction and I'd be happy to try and implement it. In the meantime, Mike, have you considered saving your queries so that you don't have to keep dealing with that form? That's what I do. I've got links at the bottom of my bugzilla page and I use the various and sundry links on the Bugs page of our wiki. To be honest, that form is such a pain that the only time I use it is for the purpose of testing.
(In reply to comment #3) > As for your observation Mike, you are correct. And to be honest, I don't think > there's anything I can do to fix the problem to which you refer because I don't > see anything that we're doing other than sitting and waiting for the form > fields to finish populating and all those object:child-changed:add events to > stop. That said... We could potentially look at all the cases where we listen for object:child-changed:add events and try to remove them so we don't need to handle that event. > Will can you think of anything we can be doing differently in Orca to solve > this problem for Mike? If there's a solution that I'm simply failing to see, > please point me in its general direction and I'd be happy to try and implement > it. Ha - let's see. When I arrow through the form with and without Orca running, the Classification field is just generally very very very very very slow. Especially when I arrow down from "Deprecated" to "Desktop". It's just a very nasty page. > Bugs page of our wiki. To be honest, that form is such a pain that the only > time I use it is for the purpose of testing. Mostly true for me, too. Note also that you do not need to have something selected in all the fields. For example, if I do end up having to use the form, I will often just tab directly to the "Component" list and select things in there, leaving the "Classification" and "Product" stuff with no selections in it.
(In reply to comment #4) > We could potentially look at all the cases where we listen for > object:child-changed:add events and try to remove them so we don't need to > handle that event. I'm not sure I follow you. We listen to that event as part of the live region support. As a test a while back, I immediately returned in onChildrenChanged() to see if examining these objects as potential live regions was the source of the problem. Apparently it wasn't as things were still incredibly slow. In related news, this just in: Check out what just got reclassified as an a11y bug: https://bugzilla.mozilla.org/show_bug.cgi?id=418845 It's original title: all gecko-related browsers are intolerably slow on the Red Hat bugzilla page loading components array That got changed to: Linux-only slowness on the Red Hat bugzilla page loading components array And today, drum roll please: Enabling a11y massively degrades performance of dynamic <option> addition
(In reply to comment #5) > (In reply to comment #4) > > We could potentially look at all the cases where we listen for > > object:child-changed:add events and try to remove them so we don't need to > > handle that event. > > I'm not sure I follow you. We listen to that event as part of the live region > support. As a test a while back, I immediately returned in onChildrenChanged() > to see if examining these objects as potential live regions was the source of > the problem. Apparently it wasn't as things were still incredibly slow. The main thing would be to see if we could prevent these events from being delivered to us in the first place. If so, that would eliminate a lot of CORBA traffic and probably speed things up a lot. But...now that you mention live region support uses it, we might need to think hard about how/why it is used and if there is something else we might listen for instead. I believe Scott thought about this pretty hard already and we might be stuck listening for the events. Scott? > In related news, this just in: Check out what just got reclassified as an a11y > bug: https://bugzilla.mozilla.org/show_bug.cgi?id=418845 Cool.
object:child-changed:add events are essential for live regions and ARIA tooltips/alerts. What could be done is to wrap the listener registration with settings.inferLiveRegions (our global live region support toggle). This may speed up the bugzilla list issue a little when live region support is turned off, but I suspect not a great deal. Please look at the informal performance test results I did for the live regions bug regarding this page http://bugzilla.gnome.org/show_bug.cgi?id=505742#c42 I believe bug #418845 is the root of the problem and an area where we might find the largest performance increase.
The bug listed above should be https://bugzilla.mozilla.org/show_bug.cgi?id=418845 , not the GNOME bug.
Out of curiosity, and because I'm now looking at label guess bugs and performance, I tossed this patch at the regression tests (or is it the other way 'round?) and while there are regressions there aren't *that many*. Therefore, I'm going to target this one for 2.24 and see if I can beat it into submission in the next couple of days.
I addressed this as part of bug 560466. *** This bug has been marked as a duplicate of 560466 ***