Closed Bug 490465 Opened 16 years ago Closed 16 years ago

Link focus gets lost when closing another tab using middle click

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.6a1

People

(Reporter: mozillabugs, Unassigned)

References

(
URL
)

Details

(Keywords: regression, verified1.9.1)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 Opening a link in another tab outlines the link. But after reading the new page and returning (by closing its tab) to the page containing the original link, the link focus outline has now disappeared. This is new in 3.5b4 (3.1b3 preserved the outline). Reproducible: Sometimes Steps to Reproduce: 1. Visit e.g. the above URL 2. Middle click a link to open it in a new tab. Focus stays in original page as I've configured it to do. The clicked link now shows a focus outline. 3. Click the new tab to view the new page, including scrolling down the page (scrolling may be involved but I couldn't confirm it). 4. Middle-click the tab to close it, revealing the original tab. Actual Results: The focus outline has disappeared from the clicked link. Expected Results: Preserve the focus outline, as in prior versions (3.1b3 preserved it). Reason: The outline makes it easier to visually find one's place and resume reading on the original page.
Summary: Link focus outline cleared when closing other tab → Link focus outline gets cleared when closing another tab
This happens also on Windows XP. Don't know if this is intentional.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Component: General → Layout
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → layout
Hardware: x86 → All
Version: unspecified → Trunk
Perhaps due to bug 462289? A regression range would be great!
Keywords: regressionwindow-wanted
Regression range in 1.9.1: Works fine: http://hg.mozilla.org/mozilla-central/rev/6cfe70091cfc Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090324 Minefield/3.6a1pre ID:20090324044213 Broken: http://hg.mozilla.org/mozilla-central/rev/85bd18f6b652 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090326 Minefield/3.6a1pre ID:20090326050203 Push log between the above regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6cfe70091cfc&tochange=85bd18f6b652 Regression range in 1.9.2: Works fine: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/4552d789ad8f Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090326 Shiretoko/3.5b4pre ID:20090326045125 Broken: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/cd99dc2701b0 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090327 Shiretoko/3.5b4pre ID:20090327044454 Push log between the above regression range: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=4552d789ad8f&tochange=cd99dc2701b0
Sorry s/in 1.9.1:/in 1.9.2:/ and s/in 1.9.2:/in 1.9.1:/
I would have to say bug 462673 in that case, nothing else seems to match...
Flags: wanted1.9.1?
I can't reproduce this. Does it strictly depend on closing the tab with a middle click? I don't have an external mouse available at the moment. Also, is the element actually unfocused, or is the focus outline just missing? I.e. what happens when you press TAB?
(In reply to comment #6) > I can't reproduce this. Does it strictly depend on closing the tab with a > middle click? I don't have an external mouse available at the moment. Yes, ctrl-w, context-menu->close don't cause this bug. > Also, is the element actually unfocused, or is the focus outline just missing? > I.e. what happens when you press TAB? The element is not focused, tabbing goes to the location bar.
[OP here:] 1) Agreed, Cmd-W (in my case) and context menu don't cause the bug. 2) Tab goes to URL bar; or Shift-Tab goes to the link following the clicked link. A second Shift-Tab goes the to the clicked link itself.
Workaround: <method name="onTabClick"> <parameter name="event"/> <body> <![CDATA[ if (event.button != 1 || event.target.localName != 'tab') return; if (this.mTabs.length > 1 || !this.mPrefs.getBoolPref("browser.tabs.closeWindowWithLastTab")) + { + content.focus(); this.removeTab(event.target); + } event.stopPropagation(); ]]> </body> </method>
Component: Layout → Tabbed Browser
Flags: wanted1.9.1?
Product: Core → Firefox
QA Contact: layout → tabbed.browser
Better Workaround: + if (event.target == gBrowser.mCurrentTab) content.focus(); I am sorry to have interfered with the argument.
It seems to me that this is (1) due to deeper focus handling weirdness, (2) partly caused or triggered by bug 462673 and (3) a side-effect of bug 482801. Fixing bug 482801 might be sufficient for 3.5, and in the longer run bug 178324 might fix the underlying issue. It's not clear to me yet that there's more to be done in tabbrowser, i.e. that the regression from bug 462673 is due to a mistake in the patch that landed there.
Blocks: 462673
Depends on: 482801
Based on <https://build.mozilla.org/tryserver-builds/2009-04-28_15:33-neil@mozilla.com-refocus7/>, bug 178324 seems to fix this indeed.
Depends on: 178324
Summary: Link focus outline gets cleared when closing another tab → Link focus gets lost when closing another tab
Summary: Link focus gets lost when closing another tab → Link focus gets lost when closing another tab using middle click
Should be fixed by bug 482801.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090506 Minefield/3.6a1pre Verified fixed.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1
[OP, again:] Confirmed fixed in 3.5b99. Thanks, all!
When verifying on 1.9.1 branch, remember to change the keyword "fixed1.9.1" to "verified1.9.1". Thanks!
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.