298077 - Link remains focused (outlined) when going back to the previous page using the back button and the focus can not be undone.

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Jeroen van der Meer]

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

Comment 1

[Jeroen van der Meer]

Attachment: HTML test case

Comment 2

[Jeroen van der Meer]

Attachment: Screenshot

Comment 3

[Steve England [:stevee]]

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)

Comment 4

[Jeroen van der Meer]

Yes.

Comment 5

[Steve England [:stevee]]

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?

Comment 6

[philippe (part-time)]

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

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 10

[Jaime Mitchell (use [e-mail] for email)]

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

Comment 11

[:Gavin Sharp [email: [e-mail]]]

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

Comment 12

[Brian Ryner (not reading)]

Attachment: patch

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

Comment 13

[Asa Dotzler [:asa]]

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

Comment 14

[Kevin Brosnan]

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

Comment 15

[Jo Hermans]

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

Comment 16

[Brendan Eich [:brendan]]

Comment on attachment 188979 [details] [diff] [review]
patch

a=me for 1.8b4.

/be

Comment 17

[Brian Ryner (not reading)]

checked in

Comment 18

[Brian Polidoro]

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.  

Comment 19

[logan]

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

Comment 20

[Dan Fischbach]

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.

Comment 21

[Adam Guthrie]

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.

Comment 22

[Asaf Romano (gone)]

Yeah, this has regressed again.

Comment 23

[Grayson Mixon (ColdFusion650)]

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

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

Comment 25

[logan]

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

Comment 26

[Boris Zbarsky [:bzbarsky]]

Looks like fallout from bug 296639... :(

Comment 27

[Aaron Leventhal]

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.

Comment 28

[Brian Ryner (not reading)]

Attachment: fix bustage from splitwindow

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

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 30

[Brian Ryner (not reading)]

checked in, hopefully this is fixed for good.

Comment 31

[logan]

Just tried 2005080520 from prometheus, looks good. :)

Comment 32

[Benoît]

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

Comment 33

[Jaime Mitchell (use [e-mail] for email)]

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

Comment 34

[Adam Guthrie]

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