Vlad Berditchevskiy Reporter
	Description • 19 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

Then the user pres Alt-Left and then Alt-Right, the keyboard focus is lost

Reproducible: Always

Steps to Reproduce:
1. Load some page with links.
2. Follow one of the links and wait until the page is loaded completely
3. Press Alt-Left
4. Press Alt-Right

NOTE: Do not press anything an don't use the mouse between steps 3 and 4!
Actual Results:  
Now the keyboard focus is lost. If you try to scroll by pressing Up/Down arrow keys or PgUp/PgDown, nothing happens.

Expected Results:  
The keyboard focus schould remain in the content area. Scrolling should work.

Please note, this bug is not the same as Bug #300761. It's about the GUI keyboard focus, not the DOM focus discussed there. This bug was not presend in previous versions of Firefox.

	Jesse Ruderman
	Comment 1 • 19 years ago

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

Please give an example with specific URLs, even if you think it happens with all pairs of pages, so people can be sure they are testing the same thing as you.

	Vlad Berditchevskiy Reporter
	Comment 2 • 19 years ago

For example, 

http://www.mozilla.org/developer/

Then activate the link "Roadmap". Then press Alt-Left, Alt-Right. The focus is lost.
I could reproduce the bug on all pages I tried. The only condition is that you wait until the page is loaded completely and don't move the focus to anywhere between steps 2 and 3.

	Aaron Leventhal
	Comment 3 • 19 years ago

Vlad, could you try creating a fresh profile and see if the bug happens there?
Just run firefox -p and it will let you create a new profile.

If you can, try it on someone else's machine who runs a different window manager. I could imagine it being related to sloppy focus settigns or something like that.

	Vlad Berditchevskiy Reporter
	Comment 4 • 19 years ago

I tried it with a new user account (fresh profile) and with another window manager (metacity instead of sawfish) - no difference. I don't use sloppy focus, BTW, and so I can't imagine how it can be related to a window manager. 

However I noticed that it seems to be related to fbcache. The bug can only be reproduced if the page is loaded from fbcache. While testing with a fresh profile I noticed that the page for some reason wasn't always loaded from fbcache when I tried it for the first time.

So, it you can't repduce this bug, please look if the page is really loaded from fbcache, and if not, just press alt-left/alt-right again and then try to scroll with arrow keys. I could always reproduce it from the second attempt, even on a fresh account.

	Vlad Berditchevskiy Reporter
	Comment 5 • 19 years ago

I checked it again with Firefox 1.5 release, both Windows and Linux, and could reproduce it on 3 different machines. So it definitely has nothing to do with a window manager.

Can really noone else reproduce this bug?

	Ian Morris
	Comment 6 • 19 years ago

I get this bug very often on a Mac running OS10.3.9. (Firefox 1.5.0.1)

Additionally, it often happens when you omit step 4. i.e, once you go back to the original page, focus is lost.

You then need to click in the page to restore focus.

	Mattias
	Comment 7 • 19 years ago

Howdy.  It appears that focus "sticks" on a page in the history cache.

Here's a way to reproduce it:
1. Go to http://www.allmusic.com/
2. Click on "new releases"
3. Try up/down arrow to scroll page (works fine)
4. Navigate back
5. Navigate forward
6. try up/down arrow to scroll page (does not work)
7. Navigate back
8. Click anywhere on blank space; not on a link
9. Navigate forward
10. Try up/down arrow to scroll page (works fine)

You can repeat steps 4-6 any number of times, and it still no keyboard scrolling until you complete step 7-9.

On many pages, this cannot be reproduced for some reason, like eBay, Google News, many news sites, etc.

I hope this one can be resolved; it's quite annoying.  Thanks!

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

	Mattias
	Comment 8 • 19 years ago

OK, so allmusic.com changed their website to set focus on a search box - the example in comment 7 no longer works.  Instead, go to http://www.mozilla.com/firefox/ and click on the "Tabbed browsing" link, following the same general idea as the example.  make sure your window is small enough that you get a scroll bar.

And, this happens in Windows:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

	Aaron Leventhal
	Comment 9 • 18 years ago

I can consistently reproduce this in Firefox 1.5 and Firefox 2 nightly builds, using the page/link provided in comment 8 (http://www.mozilla.com/firefox/ and Tabbed Browsing) and the instructions in comment 7.

However, it's consistenly fixed for me in trunk.

Confirmation please?

	Aaron Leventhal
	Comment 10 • 18 years ago

Here are the trunk builds to try:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

	Aaron Leventhal
	Comment 11 • 18 years ago

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

	Mattias
	Comment 12 • 18 years ago

(In reply to comment #9)
> I can consistently reproduce this in Firefox 1.5 and Firefox 2 nightly builds,
> using the page/link provided in comment 8 (http://www.mozilla.com/firefox/ and
> Tabbed Browsing) and the instructions in comment 7.
> 
> However, it's consistenly fixed for me in trunk.
> 
> Confirmation please?
> 

I'm sorry to bother you about this, but what does "confirmation please" mean in this context?  Do you want -anybody- (i.e. me) to download the "trunk" (whatever a trunk is?) to see if this bug can still be reproduced?  I'm going to assume this is a comment meant for a programmer unless you say otherwise.

I can still reproduce this bug in: Win XP / Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

	Aaron Leventhal
	Comment 13 • 18 years ago

Actually I can confirm this is broken in trunk too using comment 8 testcase (www.mozilla.org/firefox, click on Tabbed Browsing, Back, Forward)

According to https://bugzilla.mozilla.org/show_bug.cgi?id=318739#c1
this broke between 1.8b5_2005092513 and 1.8b5_2005092523.

Clearly something to do with fastback..

	Boris Zbarsky [:bzbarsky]
	Comment 14 • 18 years ago

OK, I've verified that setting browser.sessionhistory.max_total_viewers to 0 fixes the issue (though then when I go back the link is not focused; could that be related?)

	Aaron Leventhal
	Comment 15 • 18 years ago

(In reply to comment #14)
> OK, I've verified that setting browser.sessionhistory.max_total_viewers to 0
> fixes the issue (though then when I go back the link is not focused; could that
> be related?)

To clarify, the link would only be focused if you're using max_total_viewers > 0, because we don't have any code to remember focus history otherwise.

In any case, I'm not sure how it would be related. Scrolling happens whether a link or the document is focused, and the problem page is the one after alt+right (forward) which has no link focused in these scenarios.

	Boris Zbarsky [:bzbarsky]
	Comment 16 • 18 years ago

> because we don't have any code to remember focus history otherwise.

Ah, ok.  Didn't realize this.

So yeah, this is definitely a fastback regression.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 17 • 18 years ago

Bryner, can we get you to take a look at this for beta2?

	David Baron :dbaron:
	Comment 18 • 18 years ago

Minusing for blocking1.8.1 because it's getting hard to imagine that there would be a safe-enough patch for us to take at this point, given how fragile focus changes are, and because we did ship this in 1.8.  But it would be really good to see this fixed for 1.9a1.

	Oliver Yeoh Assignee
	Comment 19 • 18 years ago

So, what's happening in step 4 of comment 0 is that the focus controller still thinks that the focused element from the previous page is still focused.

Patch to reset the focus controller's memory before restoring the window state.

	Boris Zbarsky [:bzbarsky]
	Comment 20 • 18 years ago

The explanation in comment 19 should be in the code comments.  That is, document _why_ you're doing something, not _what_ you're doing; the latter is pretty clear from the code in this case... ;)

	Brian Ryner (not reading)
	Comment 21 • 18 years ago

Comment on attachment 239138 [details] [diff] [review]
Patch

I see, we're resetting the focused window but not doing anything with the focused element.  This seems like the right idea, but, I think it might break things if the focus controller's focused element is not part of the window that was just restored (for example, if you had focus in the url bar and then clicked back).

	Oliver Yeoh Assignee
	Comment 22 • 18 years ago

(In reply to comment #21)
> (From update of attachment 239138 [details] [diff] [review] [edit])
> I see, we're resetting the focused window but not doing anything with the
> focused element.  This seems like the right idea, but, I think it might break
> things if the focus controller's focused element is not part of the window that
> was just restored (for example, if you had focus in the url bar and then
> clicked back).
> 

Good catch! Will follow up with a new patch.

	Oliver Yeoh Assignee
	Comment 23 • 18 years ago

Updated to tip. Addresses reviews in comment 20 and comment 21

	Brian Ryner (not reading)
	Comment 24 • 18 years ago

Comment on attachment 239256 [details] [diff] [review]
Patch

looks good

	Johnny Stenback (:jst)
	Comment 25 • 18 years ago

Comment on attachment 239256 [details] [diff] [review]
Patch

sr=jst

	Boris Zbarsky [:bzbarsky]
	Comment 26 • 18 years ago

Checked in on trunk.  Oliver, thanks for the patch!

	Vlad Berditchevskiy Reporter
	Comment 27 • 18 years ago

Is this one supposed to be fixed in Firefox 2.0? I downloaded RC1, but this bug can still be reproduced there.

	Boris Zbarsky [:bzbarsky]
	Comment 28 • 18 years ago

> Is this one supposed to be fixed in Firefox 2.0?

Not so far.  Nominate the patch for the relevant branches if you feel that it should go in on there, I guess.

	Wayne Mery (:wsmwk)
	Comment 29 • 18 years ago

Comment on attachment 239256 [details] [diff] [review]
Patch

for FF2?

	Boris Zbarsky [:bzbarsky]
	Comment 30 • 18 years ago

If you _do_ nominate, be sure to give a detailed risk analysis explaining why this is a safe patch that you'd trust with your mother's life.

	Reed Loden [:reed]
	Comment 31 • 18 years ago

If you really want this looked at for Firefox 2, you should re-request blocking1.8.1? and also request approval1.8.1.1?/blocking1.8.1.1?. :)

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 32 • 18 years ago

Comment on attachment 239256 [details] [diff] [review]
Patch

Minusing for 1.8.1, forwarding request on to 1.8.1.1.

	Daniel Veditz [:dveditz]
	Comment 33 • 18 years ago

Minus for the security release... minor annoyance, no risk assessment

	Boris Zbarsky [:bzbarsky]
	Comment 34 • 18 years ago

This isn't a minor annoyance for accessibility.  It's a pretty serious issue -- it completely breaks keyboard navigation.

That said, I agree that there is some risk to this, and I have a hard time quantifying "some".  But I do think we should fix this on the 1.8.1 branch at some point; the question is when we decide it's baked enough to do it...

	Vlad Berditchevskiy Reporter
	Comment 35 • 18 years ago

BTW, those who don't want to wait for ages or compile the development branch, can use this extension:

https://addons.mozilla.org/firefox/2616/

	Mattias
	Comment 36 • 18 years ago

(In reply to comment #35)

Sweet!  Vlad, thank you so much for the link!