NVDA should take one back to the previous position on a page such as a link

[mike.reiser]

Currently, NVDA does not remember the place someone leaves off at when going back to the previous page. Steps to reproduce:

1. Go to a site such as google and do a search.

2. Follow a link of interest.

3. Press alt leftarrow or backspace to go to the previous page.

Expected results: NVDA should go back to the link the person was at when they activated it.

Actual results: NVDA goes back to the top of the page and looses place of where the person was at on the previous page. I see this only being applicable to links as one does not usually go back to previous text IE headings or paragraphs.

[jteh]

Are you referring to the new virtual buffers used in Firefox 3? NVDA does return to the correct link when I move back in Firefox 3 following your Google search example.

I have seen sites where this does not work properly. Please note that NVDA does not remember previous pages at all. It relies on the browser to correctly position the focus on the link followed to reach the next page. If this focus is not set properly for some reason, this will break. This seems to happen with Trac. I suspect Trac may be using some javascript to focus elsewhere or perhaps it is a browser bug. However, it certainly behaves correctly in the Google example for me.

[jteh]

There definitely seems to be some sort of javascript used by Trac which messes with the focus when returning to some pages. With javascript enabled, the focus gets set to the document when I press back. However, if I disable javascript, the focus is correctly returned to the link. I'm not sure if this is a Trac bug or a Firefox bug. :)

[mike.reiser]

Replying to jteh:

Are you referring to the new virtual buffers used in Firefox 3? NVDA does return to the correct link when I move back in Firefox 3 following your Google search example.

I have seen sites where this does not work properly. Please note that NVDA does not remember previous pages at all. It relies on the browser to correctly position the focus on the link followed to reach the next page. If this focus is not set properly for some reason, this will break. This seems to happen with Trac. I suspect Trac may be using some javascript to focus elsewhere or perhaps it is a browser bug. However, it certainly behaves correctly in the Google example for me.

Interesting, I just did a google search for shark. I followed a link to a wikipedia article, and when I went back it took me to the top and not the link I was on. I am refering to firefox3 and am using r2204. This happens for me consistantly on all pages.

[mike.reiser]

Replying to jteh:

There definitely seems to be some sort of javascript used by Trac which messes with the focus when returning to some pages. With javascript enabled, the focus gets set to the document when I press back. However, if I disable javascript, the focus is correctly returned to the link. I'm not sure if this is a Trac bug or a Firefox bug. :)

Just tested with both java and java script disabled, still the same results on all pages. Did another google search and still the same results. Using R 2206 source version and firefox3.

[Big.D]

Yeah I've also tried this with <a href=" http://www.zonebbs.com">The Zone BBS</a> and it doesn't return to the position I was on when I left that page either. Using r2343.

Thanks.

[jteh]

Replying to Big.D:

Yeah I've also tried this with The Zone BBS and it doesn't return to the position I was on when I left that page either. Using r2343.

It doesn't work for me there either. However, does it work for you on other sites; e.g. the Google example I provided above?

[Big.D]

Hi,

I did a google search for ESpeak varients and went to the second search result, then pressed backspace. Both with screen layout on and off, it didn't work.

Thanks.

[jteh]

I have done some more testing and can confirm that this is broken for all pages in Firefox 3.0.1. I'm not sure about 3.0. This seems to work fine in Firefox 3.0.2 and 3.1 nightlies, so it'd be good if someone having this problem could test with a nightly build of either 3.0.2 or 3.1.

I couldn't find a bug report indicating that this is a fixed regression in 3.0.2, but this does seem to be the case. Marco, are you aware of any such bug?

[jteh]

Clarification: This is still broken for me for Trac and www.zonebbs.com, but it works fine on most other pages, including the Google search example above.

[jteh]

Are those experiencing this bug running WebVisum? Can you please try the Google search scenario with WebVisum disabled? You can disable WebVisum from the Add-ons dialog. Make sure you restart Firefox after disabling it. Our testing shows that there appears to be an issue with WebVisum and returning to the correct position on a page. This obviously needs to be resolved, but I'd like to know if anyone else can confirm this.

[jteh]

Replying to jteh:

I have done some more testing and can confirm that this is broken for all pages in Firefox 3.0.1.

Note that this particular issue was fixed in 3.0.2.

[mike.reiser]

Replying to jteh:

Are those experiencing this bug running WebVisum? Can you please try the Google search scenario with WebVisum disabled? You can disable WebVisum from the Add-ons dialog. Make sure you restart Firefox after disabling it. Our testing shows that there appears to be an issue with WebVisum and returning to the correct position on a page. This obviously needs to be resolved, but I'd like to know if anyone else can confirm this.

Jamey,

Just tested with webvisum enabled and disabled with the same results. When I press alt left arrow it goes back to the previous page and NVDA starts reading from the top of the page. Pressing control on it results at me being near the top where nvda stops reading, it doesn't go right back to the previous position. Seems like when I go back it should just go to the previous position, IE a link etc. Again, I tried it with webvisum enabled, then disabled it and got the same results. Also tried disableing javascript awhile back with the same results.

[mike.reiser]

Replying to mike.reiser:

Replying to jteh:

Are those experiencing this bug running WebVisum? Can you please try the Google search scenario with WebVisum disabled? You can disable WebVisum from the Add-ons dialog. Make sure you restart Firefox after disabling it. Our testing shows that there appears to be an issue with WebVisum and returning to the correct position on a page. This obviously needs to be resolved, but I'd like to know if anyone else can confirm this.

Jamey,

Just tested with webvisum enabled and disabled with the same results. When I press alt left arrow it goes back to the previous page and NVDA starts reading from the top of the page. Pressing control on it results at me being near the top where nvda stops reading, it doesn't go right back to the previous position. Seems like when I go back it should just go to the previous position, IE a link etc. Again, I tried it with webvisum enabled, then disabled it and got the same results. Also tried disableing javascript awhile back with the same results.

I just tried the pre release nightly beta of firefox 3.1, and the issue seems to be fixed in that version. However, it's broken in 3.0.3 which is the current stable version and the one I'm using, don't know if we can get it into this version somehow. I hope this helps.

[jteh]

Bzr branch:  http://bzr.nvaccess.org/nvda/ticket132

Unfortunately, this breaks auto focus mode when focus is automatically set by the page when loaded; e.g. Google. Hopefully, the lessFreezing branch will fix this, as the virtual buffer gainFocus event is normally delayed until after the page sets the focus.

[jteh]

lessFreezing has now been merged, so the described issue is now fixed. However, this feature "remembers" the last position in cases where it perhaps shouldn't; e.g. Thunderbird or a different tab in Firefox.

This feature is still probably important, but we need more time to test it and get feedback.

[jteh]

Code no longer merges cleanly. Postponing.

[Bernd]

I'd like to test this feature. Should I use the actual snapshots or the ticket132 branch? If I use the Ticket132 branch which nvdaHelper should I use?

[jteh]

You need to use the ticket132 branch. It is currently rather out of date with main/pending, which means you'll have to build nvdaHelper from scratch with an older version of scons. It's probably worth waiting until I get a chance to sync it with something current if you're not comfortable doing this.

[mdcurran]

Considering only doing this for http urls so that this does not have bad affects in email clients etc.

[jteh]

Fresh start on the ticket132 branch. Anyone who has this should pull it from scratch or use pull --overwrite.

We now only do this for http, https, ftp, ftps and file URLs to stop it remembering positions in email clients, etc. This is only meant to work for web browsers where the browser does actually remember the scroll position but unfortunately doesn't communicate that to ATs.

[jteh]

Merged in changeset:main,4014.