Bug 36539 (focushist)

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

REOPENED
Unassigned

Status

()

Core
Document Navigation
REOPENED
17 years ago
a year ago

People

(Reporter: emk, Unassigned)

Tracking

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

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

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3] [t2], URL)

(Reporter)

Description

17 years ago
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).
(Reporter)

Comment 1

17 years ago
Sorry, please replace step 2. to step 3.

Updated

17 years ago
Target Milestone: --- → M20

Comment 2

17 years ago
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. ***

Comment 5

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 6

17 years ago
Not a dup.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 7

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

Comment 8

17 years ago
*** 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. ***

Comment 11

16 years ago
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

16 years ago
*** Bug 87830 has been marked as a duplicate of this bug. ***
Keywords: access
Giving it to pollmann.  I think the actual work is in the backend. 
Assignee: radha → pollmann
Status: REOPENED → NEW

Comment 14

16 years ago
->trudelle, isn't this on your PRD? Bryner, Hyatt and myself have talked about
how to do it, fyi.
Assignee: pollmann → trudelle

Comment 15

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

Comment 16

16 years ago
->bryner, clearing target for re-triage. 
Assignee: trudelle → bryner
Target Milestone: Future → ---

Comment 17

16 years ago
*** 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

Comment 19

16 years ago
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

Comment 20

16 years ago
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. ***

Updated

16 years ago
Blocks: 83552

Comment 23

16 years ago
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

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

Comment 25

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

Comment 26

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

Comment 27

15 years ago
Try to take this.

Comment 28

15 years ago
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

15 years ago
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.

Comment 31

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

Comment 32

15 years ago
*** 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.

Comment 34

15 years ago
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.

Comment 36

15 years ago
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

Updated

15 years ago
Status: NEW → ASSIGNED

Comment 38

15 years ago
Changing from topembed, to embed, as this is not blocking a major embedding
customer.
Keywords: topembed → embed
Whiteboard: [adt3]

Comment 39

15 years ago
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: major → enhancement

Updated

15 years ago
Summary: [RFE]Saving focused element in session history → Saving focused element in session history

Updated

15 years ago
Blocks: 176349

Comment 40

15 years ago
Bulk adding topembed keyword.  Gecko/embedding needed.
Keywords: topembed

Comment 41

15 years ago
minusing this time in the hope that it doesn't get nominated again
Keywords: topembed → topembed-

Updated

15 years ago
Whiteboard: [adt3] → [adt3] [t2]
*** Bug 181014 has been marked as a duplicate of this bug. ***

Comment 43

14 years ago
*** 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.

Comment 48

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

Updated

14 years ago
Target Milestone: mozilla1.1alpha → ---

Updated

14 years ago
Flags: blocking1.6a?

Comment 49

14 years ago
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

14 years ago
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 → --

Comment 55

14 years ago
*** Bug 229231 has been marked as a duplicate of this bug. ***
*** Bug 230782 has been marked as a duplicate of this bug. ***

Comment 57

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

Updated

13 years ago
Blocks: 24413

Comment 58

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

Comment 59

13 years ago
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

13 years ago
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

Updated

13 years ago
Blocks: 127812

Comment 61

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

Comment 62

13 years ago
*** Bug 250320 has been marked as a duplicate of this bug. ***
QA Contact: claudius → bugzilla

Comment 63

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

Comment 64

13 years ago
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

Updated

13 years ago
Alias: focushist

Comment 65

13 years ago
*** 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. ***

Comment 67

13 years ago
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?

Comment 68

13 years ago
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)

Updated

13 years ago
Flags: blocking1.8b?
Flags: blocking1.8b+
Flags: blocking1.6a-
Flags: blocking-aviary1.1+

Comment 69

13 years ago
Ginn, can you take a look?
Assignee: zhayupeng → ginn.chen

Comment 70

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

Comment 71

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

Comment 72

13 years ago
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

13 years ago
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+

Comment 74

12 years ago
(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

12 years ago
Note bug 288462.

Comment 76

12 years ago
maybe for 1.8b3
Flags: blocking1.8b2+ → blocking1.8b3+
*** Bug 294214 has been marked as a duplicate of this bug. ***

Comment 78

12 years ago
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. ***

Comment 80

12 years ago
(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

12 years ago
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. ***

Comment 83

12 years ago
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. ***

Comment 85

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

Comment 86

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

Comment 87

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

Comment 88

12 years ago
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

11 years ago
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

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

Updated

10 years ago
Blocks: 251784

Comment 91

10 years ago
Not sure if this should be a dupe of bug 251784 or not.
Blocks: 368883

Comment 92

10 years ago
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

Updated

9 years ago
Component: History: Session → Document Navigation
QA Contact: bugzilla → docshell

Updated

9 years ago
Flags: wanted1.9.1?

Updated

9 years ago
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.

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 17 years ago7 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 94

7 years ago
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 → ---
You need to log in before you can comment on or make changes to this bug.