User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050617 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050617 Firefox/1.0+ When you visit a page that has multiple links you can click on of them to go to its specified location. You can then return to the previous page using the Fast Back feature. As you see, the link is still focussed, but when you click on another link and again return to the previous page, the first link is still focused, TOGETHER with the second link. So everytime you click on a link and return to that page, the link remains focused. The only way to remove the focus is to refresh the page, or use either the TAB button or your mouse to focus the link again and then give focus to another element. Reproducible: Always

WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050618 Firefox/1.0+ ID:2005061804 Reporter, are you using bfcache? (fast back/forward)

Yes.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050618 Firefox/1.0+ ID:2005061804 I see this behaviour too. The opposite of bug 293235?

(In reply to comment #5) > Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050618 > Firefox/1.0+ ID:2005061804 > I see this behaviour too. The opposite of bug 293235? Not the opposite. The behaviour is see with this bug is that the focussing ring cannot be 'clicked away'. It is like locked. When using the back button, I think it is normal that the originating link remains focussed when returning to the originating page. But clicking anywhere on the page (move the focus to the page) doesn't remove that focus fom the link anymore.

I see this on the testcase. I also see this on http://dbaron.org/home , but only when I move the mouse off the link while the next page is loading, and there it goes away when I mouse over the link. So I suspect it has something to do with ContentStatesChanged notifications (for CSS :focus change) not being processed properly when the page is in the dead state while the next page is loading (i.e., after DocumentViewerImpl::Close).

Actually, that doesn't quite make sense, since :hover changes work fine during that period. It's more like the ContentStateChanged notification for the :focus change is never sent since the focus changes while things are disconnected.

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

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

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

SetupNewViewer nulls out the saved focus on the focus controller to avoid having it hold a reference to an element in a dead document. That's great, but we need it to happen after we've saved the focused element into the WindowStateHolder. So I hoisted the CaptureState call up to happen just a bit earlier. The result is that the link will have "real" focus when you go back, not just a focus outline. (As David suspected, the clearing of the focused element on the focus controller does not call SetFocusState, but it's ok since we will reset the focus state when restoring the presentation).

This is gonna need to make b4 if it's gonna make 1.1 so the 1.1 nomination is redundant.

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

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

Comment on attachment 188979 [details] [diff] [review] patch a=me for 1.8b4. /be

checked in

This appears to be fixed in an extensionless profile. But in 2 profiles with All-In-One Gestures I still see this problem. I'm guessing what I'm seeing probably has the same cause as the problems seen in bug 295931. So this is just an FYI.

is it just me or has this come back in today's build (20050731)?

Seems to be random in the HTML testcase on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050731 Firefox/1.0+ ID:2005073110 Try clicking the same link multiple times...it goes away after the 3rd or so Back. Weird.

I'm seeing this too. Sometimes the focus will go away when I hover over the links, but I can still get the two links focused at once thing.

Yeah, this has regressed again.

(In reply to comment #20) >it goes away after the 3rd or so Back. Weird. thats because its caused by bfcache. and by default, the max_viewers for bfcache is set to 3. hence, it goes away after going back about 3 times.

So what's the date range on this regressing just now?

2005-07-30-05-trunk is the last good build I have, 2005-07-31-05-trunk is where I first see the regression. Are there hourly builds for linux? I'd be happy to try and narrow it down some...

Looks like fallout from bug 296639... :(

It seems like more than the fact that the focus outline won't go away. We're not refocusing the document or previously focused element at all. So, arrow keys don't scroll etc. when you go back. It also breaks our new page notification in accessibility because we only fire that for focused docshells.

Use the target window's outer window when we're comparing to the focused window, since the focus manager tracks the outer window.

Comment on attachment 191739 [details] [diff] [review] fix bustage from splitwindow Yeah, I *think* the idea is that pretty much everything should be dealing with outer windows except for the stuff that has to deal with inner windows (and not the other way around). Maybe double-check that with jst, but no need to wait for that.

checked in, hopefully this is fixed for good.

Just tried 2005080520 from prometheus, looks good. :)

Have downloaded today's nightly. It's indeed fixed. -> VERIFIED

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

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