Bug 36539 (focushist)

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

REOPENED
Unassigned

Status

()

defect
REOPENED
20 years ago
4 months ago

People

(Reporter: emk, Unassigned)

Tracking

(Depends on 1 bug, Blocks 3 bugs, 4 keywords)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8b3 -
blocking-aviary1.5 -
wanted1.9.1 ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3] [t2], )

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).
Sorry, please replace step 2. to step 3.
Target Milestone: --- → M20
Move to "Future" milestone.
Target Milestone: M20 → Future
nav triage team: not a beta stopper. 
Keywords: nsbeta1-
*** Bug 62264 has been marked as a duplicate of this bug. ***
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 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Not a dup.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 50225 has been marked as a duplicate of this bug. ***
*** Bug 70794 has been marked as a duplicate of this bug. ***
*** Bug 71281 has been marked as a duplicate of this bug. ***
*** Bug 71281 has been marked as a duplicate of this bug. ***
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.
*** Bug 87830 has been marked as a duplicate of this bug. ***
Giving it to pollmann.  I think the actual work is in the backend. 
Assignee: radha → pollmann
Status: REOPENED → NEW
->trudelle, isn't this on your PRD? Bryner, Hyatt and myself have talked about
how to do it, fyi.
Assignee: pollmann → trudelle
*** Bug 100840 has been marked as a duplicate of this bug. ***
->bryner, clearing target for re-triage. 
Assignee: trudelle → bryner
Target Milestone: Future → ---
*** Bug 103837 has been marked as a duplicate of this bug. ***
targetting 0.9.7, at least until we figure out how much work this will entail.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
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?
Severity: enhancement → major
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.
Target Milestone: mozilla0.9.7 → mozilla0.9.9
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.
Keywords: helpwanted
Target Milestone: mozilla0.9.9 → mozilla1.1
*** Bug 122631 has been marked as a duplicate of this bug. ***
Blocks: focusnav
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
*** Bug 126085 has been marked as a duplicate of this bug. ***
*** Bug 125973 has been marked as a duplicate of this bug. ***
*** Bug 131428 has been marked as a duplicate of this bug. ***
Try to take this.
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);
  }
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.
cc'ing Dave Hyatt also.
*** Bug 165147 has been marked as a duplicate of this bug. ***
*** Bug 167872 has been marked as a duplicate of this bug. ***
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.
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
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.
jkeiser: Feel free to take it. I don't think I have time to do it recently. Thanks!
Taking.
Assignee: bryner → jkeiser
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Changing from topembed, to embed, as this is not blocking a major embedding
customer.
Keywords: topembedembed
Whiteboard: [adt3]
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: major → enhancement
Summary: [RFE]Saving focused element in session history → Saving focused element in session history
Blocks: grouper
Bulk adding topembed keyword.  Gecko/embedding needed.
Keywords: topembed
minusing this time in the hope that it doesn't get nominated again
Keywords: topembedtopembed-
Whiteboard: [adt3] → [adt3] [t2]
*** Bug 181014 has been marked as a duplicate of this bug. ***
*** Bug 212121 has been marked as a duplicate of this bug. ***
*** Bug 212819 has been marked as a duplicate of this bug. ***
*** Bug 213654 has been marked as a duplicate of this bug. ***
*** Bug 172532 has been marked as a duplicate of this bug. ***
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.
*** Bug 221427 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.1alpha → ---
Flags: blocking1.6a?
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."
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."
Severity: enhancement → normal
Summary: Saving focused element in session history → Accessibility: Saving focused element in session history
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
Flags: blocking1.6a? → blocking1.6a-
*** Bug 224276 has been marked as a duplicate of this bug. ***
*** Bug 226724 has been marked as a duplicate of this bug. ***
Making it clearer that no one is working on this....
Assignee: john → history
Status: ASSIGNED → NEW
Priority: P3 → --
*** Bug 229231 has been marked as a duplicate of this bug. ***
*** Bug 230782 has been marked as a duplicate of this bug. ***
*** Bug 184087 has been marked as a duplicate of this bug. ***
Blocks: uaag
*** Bug 241590 has been marked as a duplicate of this bug. ***
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.
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.
Assignee: core.history.global → pete.zha
Blocks: atfmeta
*** Bug 255764 has been marked as a duplicate of this bug. ***
*** Bug 250320 has been marked as a duplicate of this bug. ***
QA Contact: claudius → bugzilla
*** Bug 259595 has been marked as a duplicate of this bug. ***
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.
Summary: Accessibility: Saving focused element in session history → Accessibility: Saving focus & selection in session history
Alias: focushist
*** Bug 269035 has been marked as a duplicate of this bug. ***
Summary: Accessibility: Saving focus & selection in session history → Accessibility: Saving focus & selection in session history (back - forward should preserve focused/active link)
*** Bug 276574 has been marked as a duplicate of this bug. ***
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
Flags: blocking1.8b?
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
Summary: Accessibility: Saving focus & selection in session history (back - forward should preserve focused/active link) → Accessibility: Saving focus & selection in session history (back - forward should preserve focused/active link for keyboard navigation)
Flags: blocking1.8b?
Flags: blocking1.8b+
Flags: blocking1.6a-
Flags: blocking-aviary1.1+
Ginn, can you take a look?
Assignee: zhayupeng → ginn.chen
*** Bug 280703 has been marked as a duplicate of this bug. ***
*** Bug 281338 has been marked as a duplicate of this bug. ***
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.
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?
Flags: blocking1.8b+ → blocking1.8b2+
(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.
Note bug 288462.
maybe for 1.8b3
Flags: blocking1.8b2+ → blocking1.8b3+
*** Bug 294214 has been marked as a duplicate of this bug. ***
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.
*** Bug 295103 has been marked as a duplicate of this bug. ***
(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
Asa, should this still block 1.1 even though it is fixed in cases where fastback
works?
*** Bug 295842 has been marked as a duplicate of this bug. ***
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
Flags: blocking1.8b3-
Flags: blocking1.8b3+
Flags: blocking-aviary1.1-
Flags: blocking-aviary1.1+
*** Bug 299728 has been marked as a duplicate of this bug. ***
*** Bug 300761 has been marked as a duplicate of this bug. ***
*** Bug 300761 has been marked as a duplicate of this bug. ***
since fastback will be enabled by default with fx 1.5, shouldn't this bug be
marked as fixed?
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.
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.
*** Bug 337340 has been marked as a duplicate of this bug. ***
Blocks: 251784
Not sure if this should be a dupe of bug 251784 or not.
Blocks: fox3key
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.
No longer blocks: 251784
Depends on: 251784
Component: History: Session → Document Navigation
QA Contact: bugzilla → docshell
Flags: wanted1.9.1?
Assignee: ginn.chen → nobody
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.
Status: NEW → RESOLVED
Closed: 19 years ago9 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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?

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.

You need to log in before you can comment on or make changes to this bug.