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.

Move to "Future" milestone.

nav triage team: not a beta stopper.

*** 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 ***

Not a dup.

*** 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.

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

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

->bryner, clearing target for re-triage.

*** 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.

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?

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.

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.

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

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

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.

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

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

Bulk adding topembed keyword. Gecko/embedding needed.

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

*** 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. ***

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."

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

*** 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....

*** 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. ***

*** 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.

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

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

*** 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.

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

*** 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

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

Ginn, can you take a look?

*** 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?

(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

*** 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

*** 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. ***

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

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.

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.

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.

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?