36539 - (focushist) Accessibility: Saving focus & selection in session history (back - forward should preserve focused/active link for keyboard navigation)

Status: REOPENED

(Core :: DOM: Navigation, defect)

Description

[Masatoshi Kimura [:emk]]

Steps to reproduce:
1. Launch Mozilla.
2. Navigate to any page which contain the muitiple links.
3. Click any link as you like.
4. Go Back.

Actual result:
Selected element in step 2. will be forgotton.

Expected result:
Selected element in step 2. should be focused.
This feature will be very useful for keyboard operation.
IE5 works as expected (I can't replace IE since Mozilla doesn't have this 
feature).

Comment 1

[Masatoshi Kimura [:emk]]

Sorry, please replace step 2. to step 3.

Comment 2

[don]

Move to "Future" milestone.

Comment 3

[Viswanath Ramachandran]

nav triage team: not a beta stopper. 

Comment 4

[Viswanath Ramachandran]

*** Bug 62264 has been marked as a duplicate of this bug. ***

Comment 5

[Loco]

This is a duplicate of bug 62264 according to vishy, but is it just me or are 
thse two bugs saying the exact opposite of each other???

Anyway, the other bug has a bit more info.


*** This bug has been marked as a duplicate of 62264 ***

Comment 6

[Blake Ross]

Not a dup.

Comment 7

[Blake Ross]

*** Bug 50225 has been marked as a duplicate of this bug. ***

Comment 8

[Keyser Sose]

*** Bug 70794 has been marked as a duplicate of this bug. ***

Comment 9

[Boris Zbarsky [:bzbarsky]]

*** Bug 71281 has been marked as a duplicate of this bug. ***

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 71281 has been marked as a duplicate of this bug. ***

Comment 11

[Jesse Ruderman]

cc aaronl.

I was just about to file a dup of this bug.  Here's the text of my bug:


Mozilla should maintain focus within a page after leaving the page, and then 
set focus back to the focused element if the user comes back to a page.  This 
should apply to session history navigation (back, forward, etc.) and 
reloading.  Note that re-scrolling after reloading is currently broken 
(bug 46877), and re-focusing would probably share a bit of code with re-
scrolling.

Internet Explorer does this for both form elements and links.  It's handy for 
form elements because it lets you go back and fix something in a submitted form 
without ever touching the mouse, and it's handy for links (especially in 
buglists) because you can immediately see what you just clicked on.  (Note that 
for this to this work for buglists, bug 47350 or bug 55055 would also have to 
be fixed.)

Btw, IE's implementation of this feature for textboxes keeps track of which 
textbox is focused, but not where the insertion point is (or what text is 
selected).  Maybe including all of that would be overkill, dunno.

Comment 12

[WD]

*** Bug 87830 has been marked as a duplicate of this bug. ***

Comment 13

[Radha on family leave (not reading bugmail)]

Giving it to pollmann.  I think the actual work is in the backend. 

Comment 14

[saari (gone)]

->trudelle, isn't this on your PRD? Bryner, Hyatt and myself have talked about
how to do it, fyi.

Comment 15

[saari (gone)]

*** Bug 100840 has been marked as a duplicate of this bug. ***

Comment 16

[Peter Trudelle]

->bryner, clearing target for re-triage. 

Comment 17

[R.K.Aa.]

*** Bug 103837 has been marked as a duplicate of this bug. ***

Comment 18

[Brian Ryner (not reading)]

targetting 0.9.7, at least until we figure out how much work this will entail.

Comment 19

[Aaron Leventhal]

This is actually a P1 in the accessibility PRD

http://www.mozilla.org/projects/ui/accessibility/access-prd.html

Perhaps someone else besides bryner can take this one?

Comment 20

[saari (gone)]

bryner, hyatt and myself have discussed the issue, and are aware of how to
approach the fix. Anyone could do it, but good luck finding someone who can do
it sooner. It is severity major and the priority is noted. I really just don't
know who else to give it to.

Comment 21

[Brian Ryner (not reading)]

aaronl: Sorry, but I'm not going to have time for this any time soon.  If you
need this sooner, we'll need to find someone else to work on it.

Comment 22

[Brian Ryner (not reading)]

*** Bug 122631 has been marked as a duplicate of this bug. ***

Comment 23

[Aaron Leventhal]

We need to remember what is selected as well.

See checkpoint 9.4 in User Agent Accessibility Guidelines
http://www.w3.org/TR/2001/CR-UAAG10-20010912/guidelines#tech-tracking-previous-por

Comment 24

[Jesse Ruderman]

*** Bug 126085 has been marked as a duplicate of this bug. ***

Comment 25

[Jesse Ruderman]

*** Bug 125973 has been marked as a duplicate of this bug. ***

Comment 26

[WD]

*** Bug 131428 has been marked as a duplicate of this bug. ***

Comment 27

[Pete Zha]

Try to take this.

Comment 28

[Pete Zha]

I'm not sure should I make those frame which need remember focus to inherit 
nsIStateFulFrame?
Now, I can add following code to PresShell::CaptureHistoryState to store 
current focused element's key to nsILayoutHistoryState when leaving page.
But I don't know what is the best way to retrive it out when load page.
  if (aLeavingPage) {
    ...
    ...
    nsCOMPtr<nsIEventStateManager> manager;
    nsCOMPtr<nsIContent> content;
    rv = mPresContext->GetEventStateManager(getter_AddRefs(manager));
    if (NS_FAILED(rv))
      return rv;
    if (!manager)
      return NS_ERROR_FAILURE;
    rv = manager->GetFocusedContent(getter_AddRefs(content));

    nsCAutoString key;
    mFrameManager->GenerateStateKey(content, nsIStatefulFrame::eNoID, key);
    nsCOMPtr<nsIPresState> state;
    rv = NS_NewPresState(getter_AddRefs(state));
    state->SetStateProperty(NS_LITERAL_STRING("focused"), NS_LITERAL_STRING
("true"));
    historyState->AddState(key, state);
  }

Comment 29

[Aaron Leventhal]

Jay, Brian Ryner is definitely the person to ask. He did a lot of thinking about
this bug. There are difficult issues because of dynamic HTML and load order.
It's difficult to know how to relate the old saved element to the new page.

Comment 30

[Brian Ryner (not reading)]

cc'ing Dave Hyatt also.

Comment 31

[Robert Wall]

*** Bug 165147 has been marked as a duplicate of this bug. ***

Comment 32

[Aaron Leventhal]

*** Bug 167872 has been marked as a duplicate of this bug. ***

Comment 33

[John Keiser (jkeiser)]

In my opinion it is better to remember the FocusedElement at the top level
(probably in session history element, but also maybe in document element or
nsILayoutHistory).  You can use nsFrameManager::GenerateStateKey() to get a
unique string representing the element.  It won't be any better or worse than
save/restore is with respect to dynamic pages.

Comment 34

[Marek Z. Jeziorek]

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Comment 35

[John Keiser (jkeiser)]

Pete, looking at your semi-patch, I would do things a slightly different way.  I
would add methods to nsILayoutHistoryState, Get/SetFocusedElement(), and either
set a member variable or create a special entry in the hash when someone calls
it.  You *don't* want to store a layout history state with the key being the
focused element, because as you noted, it's hard to get back out.  At the very
least if you put it into the hashtable (which you would do if most pages do
*not* have focused elements), you should use some kind of standard key which is
guaranteed not to conflict with the regular key space.  This approach makes me a
little queasy, though, which is why I suggested the member variable :)  Actually
the scroll position should be stored in a member variable too, IMO, and then you
can get rid of all this funky SpecialStateId stuff.  That's only if you want to.
 I have a special cleanup planned for layout history state and I will clean that
up when I get to it.

As to *when* to save and restore, I would do it near the place where scrolling
is saved and restored, here is where:

http://lxr.mozilla.org/seamonkey/search?string=eDocumentScrollState

If you're still interested in this let me know; otherwise I will probably take it.

Comment 36

[Pete Zha]

jkeiser: Feel free to take it. I don't think I have time to do it recently. Thanks!

Comment 37

[John Keiser (jkeiser)]

Taking.

Comment 38

[Jaime Rodriguez, Jr.]

Changing from topembed, to embed, as this is not blocking a major embedding
customer.

Comment 39

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 40

[Michael Buckland]

Bulk adding topembed keyword.  Gecko/embedding needed.

Comment 41

[saari (gone)]

minusing this time in the hope that it doesn't get nominated again

Comment 42

[Boris Zbarsky [:bzbarsky]]

*** Bug 181014 has been marked as a duplicate of this bug. ***

Comment 43

[Jesse Ruderman]

*** Bug 212121 has been marked as a duplicate of this bug. ***

Comment 44

[Boris Zbarsky [:bzbarsky]]

*** Bug 212819 has been marked as a duplicate of this bug. ***

Comment 45

[Boris Zbarsky [:bzbarsky]]

*** Bug 213654 has been marked as a duplicate of this bug. ***

Comment 46

[Boris Zbarsky [:bzbarsky]]

*** Bug 172532 has been marked as a duplicate of this bug. ***

Comment 47

[Simcha-Yitzchak Lerner]

Given how often duplicates of this have been submitted, and how severely this 
impacts those who are unable (or unwilling) to use a mouse or other pointer 
device, this really should get fixed - even if it needs to be implemented in 
a "non-ideal" way.

This issue isn't an enhancement - it is a correction of a major 
accessibility/keyboard usability flaw.

Comment 48

[tyl2]

*** Bug 221427 has been marked as a duplicate of this bug. ***

Comment 49

[tyl2]

Besides website incompatibilities this is my biggest gripe about the browser.
I'm setting the 1.6a blocking flag to encourage people to take a look at it as
there's not even a proposed patch here, despite the first report being filed
back in early 2000! Even if it can't be cured right away, a partial fix would be
great. M. Lerner said it best: "This issue isn't an enhancement - it is a
correction of a major accessibility/keyboard usability flaw."

Comment 50

[S Woodside]

Severity from enhancement to normal, added Accessibility to summary. This is not
an enhancement request.

Bug 181014 : "This makes mouseless navigation very tedious if you're trying to
visit several links from a single page."

Comment 51

[Brendan Eich [:brendan]]

Comment 49 ignores the roadmap's words about shipping alpha promptly.  If there
is no patch in sight here, there is no way drivers will hold up 1.6alpha
indefinitely waiting for one.

Your best bet is to identify a hacker, or do the hacking yourself, for 1.6b, if
the patch can be small or safe enough, or just landed well and shaken out during
the beta period.

/be

Comment 52

[Mats Palmgren (inactive)]

*** Bug 224276 has been marked as a duplicate of this bug. ***

Comment 53

[Boris Zbarsky [:bzbarsky]]

*** Bug 226724 has been marked as a duplicate of this bug. ***

Comment 54

[Boris Zbarsky [:bzbarsky]]

Making it clearer that no one is working on this....

Comment 55

[Oleg Sidletskiy]

*** Bug 229231 has been marked as a duplicate of this bug. ***

Comment 56

[Boris Zbarsky [:bzbarsky]]

*** Bug 230782 has been marked as a duplicate of this bug. ***

Comment 57

[Asa Dotzler [:asa]]

*** Bug 184087 has been marked as a duplicate of this bug. ***

Comment 58

[Stefan Borggraefe]

*** Bug 241590 has been marked as a duplicate of this bug. ***

Comment 59

[Manish Jethani]

I filed a dup, bug 241590 (which is how I got here).

I have been through the code, and I can see that the EventStateManager has a
reference to the last focused element on the page. I'm not sure where the last
focused frame information is stored though.

To add this feature, I think this is what is required:

1. Add SaveState() and RestoreState() functions to the nsScrollBoxFrame class,
similar to the way it's done for FORM elements. (See
nsGenericHTMLFormElement::SetDocument(). The SetDocument() of nsScrollBoxFrame
can be similar vis-a-vis SaveState and RestoreState.)

2. In SaveState()

  key = nsContentUtils::GenerateStateKey(
    presContext->EventStateManager()->mFocus);
  save key in history against this scroll frame;

3. In RestoreState()

  get key from history;
  presContext->EventStateManager()->FocusOnKey();
  /* FocusOnKey should be similar to GetNextTabbaleContent
   * i.e. go through doc and match for key. !! expensive !! */

So every frame should remember its last focused element. Does that make sense to
anyone? And who remembers the last focused frame? I can write this, but I'll
need guidance from someone who knows this part well.

Comment 60

[Aaron Leventhal]

Bryner, Pete could you help Manish with his questions in comment 59?

Sending the bug back to Pete, in hopes of getting it worked on. John Keiser
doesn't work on Mozilla anymore.

Comment 61

[Aaron Leventhal]

*** Bug 255764 has been marked as a duplicate of this bug. ***

Comment 62

[Aaron Leventhal]

*** Bug 250320 has been marked as a duplicate of this bug. ***

Comment 63

[Aaron Leventhal]

*** Bug 259595 has been marked as a duplicate of this bug. ***

Comment 64

[Aaron Leventhal]

Changing summary to accurately reflect what UAAG calls for at
http://www.w3.org/TR/2002/REC-UAAG10-20021217/guidelines.html#tech-tracking-previous-por)

> 9.4 Restore viewport state history (P1) Techniques for checkpoint 9.4
>
>   1. For user agents that implement a viewport history mechanism, for each 
> state in a viewport's browsing history, maintain information about the point 
> of regard, content focus, and selection.
>    2. When the user returns to any state in the viewport history (e.g., via 
> the "back button"), restore the saved values for the point of regard, content 
> focus, and selection.

We have a content focus and selection, but no "point of regard" beyond that.

Comment 65

[Jesse Ruderman]

*** Bug 269035 has been marked as a duplicate of this bug. ***

Comment 66

[:Gavin Sharp [email: [e-mail]]]

*** Bug 276574 has been marked as a duplicate of this bug. ***

Comment 67

[Boris 'pi' Piwinger]

Whow, there are 29 dupes (probably some undetected ones on top), it has quite
some significant keywords, 26 votes (+1;-), is almost five years old, has a lot
of discussion how to fix it at least for easy cases, and -- probably most
importantly -- is the only thing IE can do better than Mozilla. So again, I will
ask for blocking. This should be doable.

pi

Comment 68

[Boris 'pi' Piwinger]

Adding more to the summary to make it better findable, I actually could not find
it in the first place to do missing "keyboard".

pi

Comment 69

[Kyle Yuan]

Ginn, can you take a look?

Comment 70

[Aaron Leventhal]

*** Bug 280703 has been marked as a duplicate of this bug. ***

Comment 71

[Kevin Brosnan]

*** Bug 281338 has been marked as a duplicate of this bug. ***

Comment 72

[Aaron Leventhal]

This is marked as a blocker for 1.8b and assigned to Ginn, but I don't think
anyone is currently working on it. I agree it's important to fix at some point,
but I don't think it should be a blocker right now unless someone has time to
step forward with a fix. Ginn, will you be taking a look? It seems like a very
complicated bug for us to be attempting a fix for at this stage in the cycle.

Comment 73

[Asa Dotzler [:asa]]

Still interested in chasing this for 1.1 (and so 1.8b2) Moving blocking status
out. Aaron, do you think you'll be able to look into this in the next 6 weeks or so?

Comment 74

[Aaron Leventhal]

(In reply to comment #73)
> Aaron, do you think you'll be able to look into this in the next 6 weeks or so?
No, not even in the next year, unfortunately.

Comment 75

[Daniel B.]

Note bug 288462.

Comment 76

[Asa Dotzler [:asa]]

maybe for 1.8b3

Comment 77

[:Gavin Sharp [email: [e-mail]]]

*** Bug 294214 has been marked as a duplicate of this bug. ***

Comment 78

[Aaron Leventhal]

The beauty is that this is fixed by fastback -- see
http://weblogs.mozillazine.org/chase/archives/008085.html

So we will see this for Firefox 1.1.

Comment 79

[:Gavin Sharp [email: [e-mail]]]

*** Bug 295103 has been marked as a duplicate of this bug. ***

Comment 80

[Chris]

(In reply to comment #78)
> The beauty is that this is fixed by fastback -- see
> http://weblogs.mozillazine.org/chase/archives/008085.html
> 
> So we will see this for Firefox 1.1.

wfm on the latest build as well..it's nice when a new feature or fix solves
other problems (makes life a whole lot easier!) :D

Comment 81

[Jesse Ruderman]

Asa, should this still block 1.1 even though it is fixed in cases where fastback
works?

Comment 82

[William Bumgarner [:zsinj]]

*** Bug 295842 has been marked as a duplicate of this bug. ***

Comment 83

[Asa Dotzler [:asa]]

Not gonna block on this. We might get something with fastback that makes this
better but it's not gonna happen for 1.8/1.1

Comment 84

[:Gavin Sharp [email: [e-mail]]]

*** Bug 299728 has been marked as a duplicate of this bug. ***

Comment 85

[Adam Guthrie]

*** Bug 300761 has been marked as a duplicate of this bug. ***

Comment 86

[Adam Guthrie]

*** Bug 300761 has been marked as a duplicate of this bug. ***

Comment 87

[Chris]

since fastback will be enabled by default with fx 1.5, shouldn't this bug be
marked as fixed?

Comment 88

[Jesse Ruderman]

Fastback cache size is more limited than session history by default, so if you
press Back several times in a row or after browsing in another tab, you often
won't be using fastback.

Comment 89

[Chris]

The fact that this bug has been open for almost six years, a bug that could hurt the transition for a user from IE > Firefox, should remain a priority.

Comment 90

[Jesse Ruderman]

*** Bug 337340 has been marked as a duplicate of this bug. ***

Comment 91

[Aaron Leventhal]

Not sure if this should be a dupe of bug 251784 or not.

Comment 92

[Marc Bejarano]

aaron: bug 251784 is meta bug to track bugs that cause scroll position to not be restored correctly.  this bug is accessibility-related and is about remembering where we were so keyboard navigators can pick up where they left off.  they aren't dupes.  i switched this to depend bug 251784 instead of vice versa.

Comment 93

[[not reading bugmail]]

I believe the latest version of the trunk 1.9.3 now saves anchored links to history if users click on them as well as the page without anchors.

Comment 94

[Masatoshi Kimura [:emk]]

Gecko 2.0 focused element memory is not better than Gecko 1.9.2 or earlier. It will be preserved only when the page is in the bfcache (see comment 88).
sasseionstore.js does not contain any information about a focused element.
Reopening.

Comment 95

[Robin Whittleton]

I tried to see if I could replicate this from comment #88 and comment #94, but with no luck. Is this still an issue? If so, does anyone have replication steps?

Comment 96

[Karl Dubost💡 :karlcow]

There is an example of this in https://webcompat.com/issues/28121
Because of the difference of behavior in between chrome and firefox, an issue was reported on webcompat.

Comment 97

[Stephen Donner [:stephend] Not actively reading bugmail]

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)

Comment 98

[Karl Dubost💡 :karlcow]

setting as P3. It seems more like a UX issue, Might be of interests Brian Grinstead because the origin of the webcompat issue is maybe? about bfcache.