After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 432751 - Firefox: Make navigation queries asynchronous
Firefox: Make navigation queries asynchronous
Status: RESOLVED WONTFIX
Product: lsr
Classification: Deprecated
Component: extensions
0.5.x
Other Linux
: Normal normal
: ---
Assigned To: LSR maintainers
LSR maintainers
gnome[unmaintained]
Depends on:
Blocks: docnav
 
 
Reported: 2007-04-23 20:48 UTC by Peter Parente
Modified: 2011-07-06 06:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Peter Parente 2007-04-23 20:48:08 UTC
This is a very long term, and experimental feature. I'm filing it here for reference.

Searching for the next or previous X could turn into a very time consuming operation. Say the user searches for the next form element on a gigantic page (e.g. Digg comment page) after navigating just past the last form element (e.g. search box at the top). The search has to proceed through all content on the page. If this operation is done synchronously, LSR becomes unresponsive (and the whole desktop because of the annoying coupling bug).

Collection will save us somewhat because the majority of the search is done by the  bridge. Therefore, cross process calls are limited to one from the client. Still, on substantially large pages, even this call may take a long time to return.

CORBA calls can be done asynchronously. This will work well when we have Collection and need to make only a handful of calls to collect matches. It doesn't help us at all at present because the search is broken up over numerous AT-SPI calls from the client.

We need some data about how responsive navigation is in the current implementation. Then we'll need to decide whether to investigate some "chunking" scheme to make navigation more responsive now, or to declare what we have "good enough" until Collection arrives.
Comment 1 Scott Haeger 2007-04-24 13:30:51 UTC
As recommended, I used a story page from digg.com as a test case.  The test page was 213 kilobytes in length with 97 posted comments.  The test involved searching for a visited link from the 'digg' link at the very top left to 'HOME' in the footer under 'Site Links'.  Here are the results from three tests:

using go to next:  14.5 secs.  1596 nodes traversed.
using go to prev:  17.7 secs.  1803 nodes traversed.

Below is the predicate used during the search:

def _visitedlinkpred(self, por):
    attrs = self.getAccAttrs(por=por)
    try:
      return (attrs['tag'] == 'A' \
              and self.hasAccState('visited', por=por)) 
    except:
      return False
Comment 2 Akhil Laddha 2011-07-06 06:40:51 UTC
lsr (Linux Screen reader) development has been stalled and it has been unmaintained for a few years now. Maintainers don't have future development plan so i am closing the bugs as WONTFIX. Please feel free to reopen the bugs in future if anyone takes the responsibility for active development.