Open
Bug 36539
(focushist)
Opened 25 years ago
Updated 2 years ago
Accessibility: Saving focus & selection in session history (back - forward should preserve focused/active link for keyboard navigation)
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
REOPENED
Webcompat Priority | P3 |
People
(Reporter: emk, Unassigned, NeedInfo)
References
(Depends on 1 open bug, Blocks 2 open bugs, )
Details
(4 keywords, 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).
Reporter | ||
Comment 1•25 years ago
|
||
Sorry, please replace step 2. to step 3.
Updated•25 years ago
|
Target Milestone: --- → M20
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: 24 years ago
Resolution: --- → DUPLICATE
Comment 10•24 years ago
|
||
*** Bug 71281 has been marked as a duplicate of this bug. ***
Comment 11•24 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•23 years ago
|
||
*** Bug 87830 has been marked as a duplicate of this bug. ***
Comment 13•23 years ago
|
||
Giving it to pollmann. I think the actual work is in the backend.
Assignee: radha → pollmann
Status: REOPENED → NEW
Comment 14•23 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•23 years ago
|
||
*** Bug 100840 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
->bryner, clearing target for re-triage.
Assignee: trudelle → bryner
Target Milestone: Future → ---
Comment 17•23 years ago
|
||
*** Bug 103837 has been marked as a duplicate of this bug. ***
Comment 18•23 years ago
|
||
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•23 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•23 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.
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Comment 21•23 years ago
|
||
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
Comment 22•23 years ago
|
||
*** Bug 122631 has been marked as a duplicate of this bug. ***
Comment 23•23 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•23 years ago
|
||
*** Bug 126085 has been marked as a duplicate of this bug. ***
Comment 25•23 years ago
|
||
*** Bug 125973 has been marked as a duplicate of this bug. ***
Comment 26•23 years ago
|
||
*** Bug 131428 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
Try to take this.
Comment 28•23 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•23 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.
Comment 30•23 years ago
|
||
cc'ing Dave Hyatt also.
Comment 31•22 years ago
|
||
*** Bug 165147 has been marked as a duplicate of this bug. ***
Comment 32•22 years ago
|
||
*** Bug 167872 has been marked as a duplicate of this bug. ***
Comment 33•22 years ago
|
||
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•22 years ago
|
||
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Comment 35•22 years ago
|
||
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•22 years ago
|
||
jkeiser: Feel free to take it. I don't think I have time to do it recently. Thanks!
Updated•22 years ago
|
Status: NEW → ASSIGNED
Comment 38•22 years ago
|
||
Changing from topembed, to embed, as this is not blocking a major embedding
customer.
Comment 39•22 years ago
|
||
[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
Comment 41•22 years ago
|
||
minusing this time in the hope that it doesn't get nominated again
Updated•22 years ago
|
Whiteboard: [adt3] → [adt3] [t2]
Comment 42•22 years ago
|
||
*** Bug 181014 has been marked as a duplicate of this bug. ***
Comment 43•21 years ago
|
||
*** Bug 212121 has been marked as a duplicate of this bug. ***
Comment 44•21 years ago
|
||
*** Bug 212819 has been marked as a duplicate of this bug. ***
Comment 45•21 years ago
|
||
*** Bug 213654 has been marked as a duplicate of this bug. ***
Comment 46•21 years ago
|
||
*** Bug 172532 has been marked as a duplicate of this bug. ***
Comment 47•21 years ago
|
||
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•21 years ago
|
||
*** Bug 221427 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Target Milestone: mozilla1.1alpha → ---
Comment 49•21 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•21 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 51•21 years ago
|
||
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-
Comment 52•21 years ago
|
||
*** Bug 224276 has been marked as a duplicate of this bug. ***
Comment 53•21 years ago
|
||
*** Bug 226724 has been marked as a duplicate of this bug. ***
Comment 54•21 years ago
|
||
Making it clearer that no one is working on this....
Assignee: john → history
Status: ASSIGNED → NEW
Priority: P3 → --
Comment 55•21 years ago
|
||
*** Bug 229231 has been marked as a duplicate of this bug. ***
Comment 56•21 years ago
|
||
*** Bug 230782 has been marked as a duplicate of this bug. ***
Comment 57•21 years ago
|
||
*** Bug 184087 has been marked as a duplicate of this bug. ***
Comment 58•21 years ago
|
||
*** Bug 241590 has been marked as a duplicate of this bug. ***
Comment 59•21 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•21 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
Comment 61•20 years ago
|
||
*** Bug 255764 has been marked as a duplicate of this bug. ***
Comment 62•20 years ago
|
||
*** Bug 250320 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
QA Contact: claudius → bugzilla
Comment 63•20 years ago
|
||
*** Bug 259595 has been marked as a duplicate of this bug. ***
Comment 64•20 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•20 years ago
|
Alias: focushist
Comment 65•20 years ago
|
||
*** Bug 269035 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Summary: Accessibility: Saving focus & selection in session history → Accessibility: Saving focus & selection in session history (back - forward should preserve focused/active link)
Comment 66•20 years ago
|
||
*** Bug 276574 has been marked as a duplicate of this bug. ***
Comment 67•20 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•20 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•20 years ago
|
Flags: blocking1.8b?
Flags: blocking1.8b+
Flags: blocking1.6a-
Flags: blocking-aviary1.1+
Comment 70•20 years ago
|
||
*** Bug 280703 has been marked as a duplicate of this bug. ***
Comment 71•20 years ago
|
||
*** Bug 281338 has been marked as a duplicate of this bug. ***
Comment 72•20 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•20 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•20 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•20 years ago
|
||
Note bug 288462.
Comment 77•20 years ago
|
||
*** Bug 294214 has been marked as a duplicate of this bug. ***
Comment 78•20 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.
Comment 79•20 years ago
|
||
*** Bug 295103 has been marked as a duplicate of this bug. ***
Comment 80•20 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•20 years ago
|
||
Asa, should this still block 1.1 even though it is fixed in cases where fastback
works?
Comment 82•20 years ago
|
||
*** Bug 295842 has been marked as a duplicate of this bug. ***
Comment 83•19 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+
Comment 84•19 years ago
|
||
*** Bug 299728 has been marked as a duplicate of this bug. ***
Comment 85•19 years ago
|
||
*** Bug 300761 has been marked as a duplicate of this bug. ***
Comment 86•19 years ago
|
||
*** Bug 300761 has been marked as a duplicate of this bug. ***
Comment 87•19 years ago
|
||
since fastback will be enabled by default with fx 1.5, shouldn't this bug be
marked as fixed?
Comment 88•19 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•19 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•19 years ago
|
||
*** Bug 337340 has been marked as a duplicate of this bug. ***
Comment 92•18 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.
Component: History: Session → Document Navigation
QA Contact: bugzilla → docshell
Updated•16 years ago
|
Flags: wanted1.9.1?
Comment 93•15 years ago
|
||
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•14 years ago
|
Status: NEW → RESOLVED
Closed: 24 years ago → 14 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 94•14 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 → ---
Comment 95•7 years ago
|
||
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•6 years ago
|
||
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.
See Also: → https://webcompat.com/issues/28121
Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)
Updated•3 years ago
|
Webcompat Priority: --- → ?
Comment 98•3 years ago
|
||
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.
Webcompat Priority: ? → P3
Flags: needinfo?(bgrinstead)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•