GNOME Bugzilla – Bug 558516
Traceback when navigating on huge webpages
Last modified: 2008-11-26 14:46:58 UTC
Steps to reproduce: 1. 2. 3. Dear Developers! I launched Mozilla Firefox 3.0 webpage, and press ctrl+l keystroke. Paste the http://people.ubuntu.com/~mvo/nightmonkey/universe-hu.html webpage address and pressing enter key. The download process is 100% completed, Orca says the "befejezett mutatása/elrejtése" text (finished shows/hidden in english). After this, the where am I command, structural navigation commands not functioning. This webpage is an important package description translation webpage in hungarian. For Jaws For Windows, this homepage functioning correctly, easy to navigating the package description table. I make a debug.out file, and I see lot of traceback messages after the "befejezett elrejtése/mutatása" text. Some traceback messages: Traceback (most recent call last):
+ Trace 208910
consumed = self.function(script, inputEvent)
self.doWhereAmI(inputEvent, True)
return self.whereAmI.whereAmI(obj, basicOnly)
where_am_I.WhereAmI.whereAmI(self, obj, basicOnly)
self._speakLink(obj, basicOnly)
link_uri = self._script.getURI(obj)
return ihyperlink.getURI(0)
^^^^^ PROCESS KEY PRESS EVENT KP_Enter ^^^^^ DEQUEUED KEYRELEASE 'KP_Enter' (104) <---------- vvvvv PROCESS KEY RELEASE EVENT KP_Enter vvvvv ^^^^^ PROCESS KEY RELEASE EVENT KP_Enter ^^^^^ KEYEVENT: type=0 hw_code=105 modifiers=0 event_string=(Control_R) is_text=True time=1225364347.822807 orca.keyEcho: string to echo: Control_R orca.isModifierKey: returning: True orca.isModifierKey: returning: True orca.isModifierKey: returning: True KEYEVENT: type=1 hw_code=105 modifiers=4 event_string=(Control_R) is_text=True time=1225364348.019203 orca.isModifierKey: returning: True orca.isModifierKey: returning: True KEYEVENT: type=0 hw_code=104 modifiers=0 event_string=(KP_Enter) is_text=True time=1225364349.550546 orca.keyEcho: string to echo: KP_Enter orca.isModifierKey: returning: False orca.isNavigationKey: returning: False orca.isPrintableKey: returning: False orca.isLockingKey: returning: False orca.isFunctionKey: returning: False orca.isActionKey: returning: False orca.keyEcho: event string not handled: KP_Enter orca.isModifierKey: returning: False ----------> QUEUEING KEYPRESS 'KP_Enter' (104) DEQUEUED KEYPRESS 'KP_Enter' (104) <---------- vvvvv PROCESS KEY PRESS EVENT KP_Enter vvvvv BRAILLE LINE: 'Befejezett elrejtése/mutatása' VISIBLE: 'Befejezett elrejtése/mutatása', cursor=1 88 label=<> 88 name=<http://people.ubuntu.com/~mvo/nightmonkey/universe-hu.html> default.getKeyBinding: ['', '', ''] 73 label=<> 73 name=<> whereAmI: label= name=http://people.ubuntu.com/~mvo/nightmonkey/universe-hu.html role= keybinding=['', '', ''] parent label= parent name= parent role=invalid basicOnly=True Traceback (most recent call last):
I sending attachment the full debug.out file. Thanks, Attila Stack trace: Other information:
Created attachment 121636 [details] This is my full debug.out file with demonstrate what happen when I try using the problem webpage (universe translation page).
While I'm moving away from Firefox/Gecko access to work on other Orca bugs/RFEs, hangs are bad so I'll take this one.
Joanmarie, possible fix this bug with relative short time period? Why have the problem Orca this webpage? Attila
Will, I could use your thoughts on this one. I can: * Add some bullet proofing in getURI to stop the traceback in the opening report. * Add a check in _getTableCaption that says, if this is an enormous table, don't bother looking for the caption. * Add a hack in goObject that says, if the current object has an ancestor that is an enormous table and the structural navigation type is not visited link or unvisited link, just assume what we're looking for ain't in this table and move to the beginning/end before searching for the next heading/list/whatever. What I can't figure out is this: If one is say, on the button at the top of the page and presses H to find the next heading, one is going to encounter a table which happens to have 14070 children and collection is going to grind everything to a halt. And with FF 3.0, terminating Orca without cleaning up the collection query takes Firefox out with it. 3.1 seems a little more forgiving, but the root problem is the same. This seems to be what Attila is experiencing. :-( If we knew in advance that this enormous table were present, we could temporarily not use collection and do the 'probably not in here' hack described above. But I don't know how to detect this in advance without gathering info about the entire page's contents immediately after the page has loaded. I'll "sleep on it," but right now I'm stumped. Is there something clever we can do here?
(In reply to comment #4) > Will, I could use your thoughts on this one. So...the main problem is that we're encountering a table with 14070 children and we and/or the collections API grinds to a halt when going through it. Is that right? If so, your strategies seem sound. For the _getTableCaption issue, I was wondering if the collections API could be used to find the table caption. Since it seems to grind to a halt, however, I guess it's not going to help. The other thing I wonder is what will need to be done to fix where_am_I as well. It uses the collections API to get page summary information, right? > I'll "sleep on it," but right now I'm stumped. Is there something clever we can > do here? Yech. I don't know. :-( I'll try to think about it as well. I wonder our Gecko internals guys have any ideas? I'm CC'ing Ginn Chen.
Created attachment 123051 [details] [review] stop the tracebacks and get the caption via the table interface The enormous table in question is gone, but I did some experiments by creating a table based on that. Given that most tables simply aren't *that* huge, and given that there might be headings and other things in a huge table that we do not want to skip over, this patch only does the following: 1. Wraps a couple of calls in a try/except to eliminate the tracebacks 2. Gets the caption directly rather than examine the children. Ultimately, it would be cool if we could figure out a way to deal with these edge cases, but in the interim this should help. As a related aside, FF 3.0 is more likely to completely tank if the use of collection goes south; FF 3.1 does not seem to suffer this problem. Things will still take a long time in a huge table, but the fact that it doesn't crash helps a bit. Will, thoughts?
Looks simple *and* good. I say check it into trunk and ask people to test it over the next couple days. If it seems good, then check it into gnome-2-24 for GNOME 2.24.2. Thanks!
Tested the fix with large webpage (large table). Going the https://wiki.ubuntu.com/HungarianTeam/TranslationCoordination webpage, and click for example with universe package table. This is very lot of elements. The Orca wait lot of time when showing the table with t key. For example the multiverse table is work fine (smaller table). Attila
Thanks Attila. The fact that structural navigation is painfully slow given an enormous table is, sadly, a known issue. We're looking at what we can do on our end to improve that. In terms of this bug, stopping the tracebacks is at least a step in the right direction -- and what we can do for the upcoming 2.24.2 release. I'll open a new bug on the broader issue.
Patch committed to trunk. Moving to pending. If all is well, then I'll check it into the gnome-2-24 branch.
Joanmarye, paste your opened bug link this bugreport? Your openion possible fastest the structural navigation (table navigation) with 2.26 Orca version with large tables? For example with this problem webpages? I not home this weekend, possible test your patch with next monday. Attila
I opened bug 561722 for the overall issue. Attila we will do our best to get to this sooner rather than later.
I went ahead and committed the patch to the gnome-2-24 branch so that it is included in the 2.24.2 release.
I haven't been able to make this fail.
Thanks Mike. Closing this one as FIXED.