Comment 1 by jteh on 2008-07-09 01:20
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.
Changes:
Milestone changed from 0.6p2 to 0.6

Comment 2 by jteh on 2008-07-09 01:37
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. :)

Comment 3 by mike.reiser (in reply to comment 1) on 2008-07-09 14:14
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.

Comment 4 by mike.reiser (in reply to comment 2) on 2008-07-09 15:54
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.

Comment 5 by Big.D on 2008-08-09 23:40
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.

Thanks.

Comment 6 by jteh (in reply to comment 5) on 2008-08-11 23:07
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?

Comment 7 by Big.D on 2008-08-11 23:56
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.

Comment 8 by jteh on 2008-08-26 04:16
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?

Comment 9 by jteh on 2008-08-26 04:18
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.

Comment 10 by jteh on 2008-10-16 22:18
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.

Comment 11 by jteh (in reply to comment 8) on 2008-10-16 22:20
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.

Comment 12 by mike.reiser (in reply to comment 10) on 2008-10-17 04:03
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.

Comment 13 by mike.reiser (in reply to comment 12) on 2008-10-17 04:23
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.

Comment 16 by jteh on 2009-06-29 09:20
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.

Comment 17 by jteh on 2009-08-28 05:39
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.
Changes:
Milestone changed from 2009.1 to 2009.2

Comment 18 by jteh on 2010-01-19 04:48
Code no longer merges cleanly. Postponing.
Changes:
Milestone changed from 2010.1 to 2010.2

Comment 19 by Bernd on 2010-03-03 13:27
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?

Comment 20 by jteh on 2010-03-23 08:31
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.

Comment 21 by jteh on 2010-07-14 04:13
Changes:
Milestone changed from 2010.2 to 2010.3

Comment 22 by mdcurran on 2010-11-24 05:15
Considering only doing this for http urls so that this does not have bad affects in email clients etc.

Comment 23 by jteh on 2011-01-12 07:56
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.

Comment 24 by jteh on 2011-01-17 00:32
Merged in 8c86ee7.
Changes:
State: closed