404060 - Returning to a previous web page (with Alt+Left-Arrow) puts one at top of page rather than on the hyperlink originally traversed.

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Janina Sajka]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2pre) Gecko/2007111311 Fedora/3.0b2pre-2007111215_trunk.fc8 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2pre) Gecko/2007111311 Fedora/3.0b2pre-2007111215_trunk.fc8 Minefield/3.0b2pre

An rpm build for Fedora 7, based on the nightly from October 20, behaves correctly. The problem has reappeared with the Firefox 3 Beta release--but see more details below. Note that other users, on Linux and Windows, confirm this bug for me--but only I seem to have seen it fixed previously.

Reproducible: Always

Steps to Reproduce:
1.Choose any hyperlink on a page and traverse it. The new page loads.
2.Return to the first page using Alt+Left-Arrow
3.Usually, you are at top of page. See Additional Info below.
Actual Results:  
I am placed at top of page.

Expected Results:  
I should be on the hyperlink I traversed.

I do NOT see the problem at bugzilla.mozilla.org. This location behaves correctly, e.g. Select Thunderbird, return with Alt+Left-Arrow, you are back on "Thunderbird." However, other pages--Google search, www.giamusic.com, etc., seem all to misbehave consistently. I have not found a page that DOESN'T misbehave as described EXCEPT bugzilla.mozilla.org.

Comment 1

[Aaron Leventhal]

Marco, can you confirm this?

From my experience the focus history only works if the entire page is stored in "fastback" memory. If you go back enough pages or to another tab and surf for a while before coming back, it erases that memory.

Comment 2

[Marco Zehe (:MarcoZ)]

(In reply to comment #1)
> Marco, can you confirm this?

Yes, I can. And we briefly touched this subject at the summit, too. For example:

1. I often visit www.heise.de/newsticker
2. Select an article under the headings that are dates.
3. After reading the article, I press Alt+LeftArrow.

On both Windows and Linux, I usually don't get back to the link I last selected, but land somewhere near the top of the page.

> From my experience the focus history only works if the entire page is stored in
> "fastback" memory. If you go back enough pages or to another tab and surf for a
> while before coming back, it erases that memory.
 
This is definitely directly after going forward and coming back.

Comment 3

[Gregory J. Rosmaita]

i can replicate the problem outlined above by both janina sajka and marco zehe
using:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111605 Minefield/3.0b2pre

with WinXP MCE 2005 Edition, SP2 on a machine with an AMD Athlon 64 Processor running at 2.40GHz and with 960GB of RAM

after going forward and coming back, instead of returning to the link i followed, i am taken to the top of the document to which i returned

Comment 4

[Janina Sajka]

(In reply to comment #3)
> i can replicate the problem outlined above by both janina sajka and marco zehe
> using:
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111605
> Minefield/3.0b2pre
> 
> with WinXP MCE 2005 Edition, SP2 on a machine with an AMD Athlon 64 Processor
> running at 2.40GHz and with 960GB of RAM
> 
> after going forward and coming back, instead of returning to the link i
> followed, i am taken to the top of the document to which i returned
> 

Gregory, Marco: I was very pleasantly surprised to find this bug doesn't show up with the hyperlinks on bugzilla.mozilla.org. Can you confirm this exception? In other words, when I traversed the "Thunderbird" link and then came back with Alt+Left-Arrow, I found myself exactly where I should be--back on the "Thunderbird" link. If this is truly a replicable exception, it may be helpful for Aaron, et al, to know that.

Comment 5

[Aaron Leventhal]

There may be something in some pages that prevent them from being stored in the fastback cache. We only remember the focus for pages stored there. They may have changed which pages are stored, to try to make Mozilla less of a pig.

The bug to do it for all pages has been around for a long time. Because of dynamic content it's not trivial: bug 36539
I don't think we can do the optimal fix now.

BTW, Windows screen readers tend to do this with their own focus tracking.

Comment 6

[Gregory J. Rosmaita]

in regards Comment #4

on the box described in Comment #3, bugzilla.mozilla.org does NOT act any 
differently with JAWS (8.0.2173 Unicode) than any other page -- let me be 
more precise:

when navigating to a page from an internal link, and then returning to the 
original document, focus is NOT returned to where it was when i left the 
original document; this, however, does not mean that it is consistently 
refocused in the same place (such as, in your report, the top of the 
original) document -- sometimes the return point-of-regard/focus is 
returned somewhere in the vicinity of the link used to navigate away from 
the original document, and i have noted that this behavior is most likely 
to occur in documents that use DIV and CSS to control layout (as opposed 
to using TABLE for layout purposes); in a document with multiple DIVs 
(such as http://www.webbie.org.uk/about.htm) when i navigate away from 
the primary document, and then use ALT+LeftArrow to return to the 
primary document, focus will be re-established somewhere within the DIV 
that contained the followed link...

2. i also plan on documenting whether i can replicate this behavior on my 
laptop, which runs straight WinXP Pro SP2; i will not only test FF3 and JAWS 
(8.0.2173 Unicode) but NVDA and FireVox as well...

Comment 7

[James Teh [:Jamie]]

For me, WebVisum seems to break focus restoration for all pages. (Perhaps it breaks fastback?) See my post here:
http://webvisum.com/pipermail/webvisum-discuss/2009-March/000328.html
While it is possible that this is an issue in WebVisum, I thought it worth noting here.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 9

[alexander :surkov (:asurkov)]

Marco, is it still issue?

Comment 10

[Marco Zehe (:MarcoZ)]

Fixed by bug 673958.