stuck focus ring on link after opening it in a new tab




Event Handling
15 years ago
8 years ago


(Reporter: Brian Ryner (not reading), Unassigned)



Firefox Tracking Flags

(Not tracked)



(1 attachment)



15 years ago
This has been around for a _long_ time, but I couldn't find any current bug
filed about it.  If you open a link in a new tab (doesn't matter if it's in the
background or not), the focus ring around the link on the original page becomes
stuck.  It doesn't go away if you focus something else.  The only way I've found
to get rid of it is to right-click the link to bring up the context menu, then
click in the blank area of the page.  If you open several links in a new tab
this way, you can end up with a large number of stuck focus rings.

Comment 1

15 years ago
bug 161625

next time try including duplicates in your search query
(resoltion:---, resolution: duplicate, status: {none})

*** This bug has been marked as a duplicate of 9809 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
Um..  This bug is indeed bug 161625 but it's not clear that it has something to
do with bug 9809.

I'm reopening this, since bryner is the one who has the best chance of fixing
it, and the fact that he assigned it to himself indicates that he plans to do so...
Resolution: DUPLICATE → ---

Comment 3

14 years ago
Hmm...well, I have a similar, but slightly difference case that also seems to
have been around for quite a while but only recently was I able to identify and
reproduce it.  I'm using "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1":

1. Add a link to a folder on your bookmarks toolbar.
2. Left-click the folder so a popup window containing the link appears beneath
the folder.
3. Right-click on the link and select "Open in New Tab"
4. Note that the folder (button) you clicked on is still depressed.  The 'focus'
appears to still be on the popup menu that appeared beneath the folder, though
the window no longer exists.  This is why when I open a link in a new tab to a
page with a form, I can't type into it.  Even worse, typing keystrokes can cause
other links in the same bookmark folder to be opened in the new tab.

Comment 4

14 years ago
This bug is a dup of bug 150322.  And so is bug 161625.  (bz, why did you reopen
this bug instead of 161625?)


11 years ago
Assignee: bryner → events
QA Contact: desale → ian

Comment 5

8 years ago
I have another case of stuck focus ring: having a frameset document with navigation and content frames, I'm adding a listener for "DOMFrameLoaded" event of top window that focuses content frame (e.taget.contentWindow.focus();), and it results in obsolete focus rings on every clicked nav link.
Which version are you using? Could you please try the latest nightly 1.9.2. It has
the new focus manager.
If you have a *minimal* testcase, would be great if you could attach it to this
bug using "Add an attachment ".

Comment 7

8 years ago
Created attachment 384606 [details]
Testcase for Firefox 3.5: obsolete focus rings after focusing another frame

1. Open index.html
2. Click the first link
3. While frame is loading, move the cursor away from the link (focus rings seem to reset on mousemove)
4. After frame is loaded, hit PgDown to check if it's focused. Note that focus ring is still present on the link 1.
5. Click the second link. In 1.9.1 you now have both links with focus rings.

This testcase doesn't work with 1.9.2: frame window doesn't receive focus after "" line.
(In reply to comment #7)
> This testcase doesn't work with 1.9.2: frame window doesn't receive focus after
> "" line.
Enn, any idea about this?

Comment 9

8 years ago
Seems like the call to GetPreviousViewer() within nsGenericHTMLFrameElement::IsHTMLFocusable returns something so makes the frame non-focusable. I don't know what a value from GetPreviousViewer() means though.

It works if focus is done after a short delay.

Comment 10

8 years ago
(In reply to comment #9)
> It works if focus is done after a short delay.
Indeed. Further testing reveals that bug I described is fixed in 1.9.2. Is there a chance to get it fixed in 3.5 release as well?
Assignee: events → nobody
QA Contact: ian → events
You need to log in before you can comment on or make changes to this bug.