Open Bug 226525 Opened 16 years ago Updated 6 years ago
Right clicking on a tab and then left clicking on another tab does not activate the other tab
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031023 Firebird/0.7+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031023 Firebird/0.7+ Let's say you have two tabs. Tab1 and Tab2. You right click on Tab1 and bring up it's context menu. Then you left click on Tab2. Results: The Context Menu disappears. Expected Result: The Context Menu should disappear, and the tab should come to the front (be activated) as though you have to click on it. Reason: You have to perform a second mouse click to bring the tab to the front. This adds uneccessary mouse clicking to the process and gives an overall impression of sluggishness. Reproducible: Always Steps to Reproduce:
Confirming on Windows XP. This bug probably shouldn't be an All/All bug because the Firebird should only do this if it is the expected behaviour on that platform. On Linux (I believe that) left clicking somewhere when something else is right clicked does not bestow focus. On Windows it does. Hence I'm moving this over to Windows, and also tweaking some other stuff.
Assignee: blake → hyatt
Severity: normal → minor
Status: UNCONFIRMED → NEW
Component: General → Toolbars
Ever confirmed: true
OS: All → Windows XP
QA Contact: bugzilla
Hardware: All → PC
Summary: Right clicking on a tab and then left clicking on another tab does not activate the other tab. → Right clicking on a tab and then left clicking on another tab does not activate the other tab
On Windows, other context menus in Firebird (toolbar, content area) don't eat clicks. Only the tab context menu does. It doesn't matter what you left-click on, but it does matter which context menu is open.
Assignee: hyatt → nobody
QA Contact: bugzilla → toolbars
Actually, there is a "nuance" related to this: 1. Open at least two tabs 2. Load a web page into each tab 3. Right click on any tab that is in the background 4. Select the "Reload Tab" menu option. Actual Result: The right-click actually performs the reload on the page where the right-click was made, even though there is no visual indication that the tab focus has changed. Expected Result: The right-click, if displaying a context menu in the context of the background tab that has been click on, should bring that tab to the front and then perform the operation. Comments: I call this a "nuance" and not a bug because it appears, on the Windows platform at least, that there is no standard for defining the operation in this case. This is because the system Tab Control does not have built in context menu handling - it is up to the programmer to display and remove any menu that needs to be displayed manually. I even saw one application where you could click on a background tab and a context menu would appear and the action you chose then applied to the original tab - very confusing. However, as there is no convention on Windows, this allows us to propose a solution. The intuitive behaviour is that if you right click on something that does not have focus at the time then that thing should be brought into focus if, and only if, a context menu is to be displayed. If no context menu exists for the item that is right-clicked then it should NOT be brought into the foreground - it should remain in the background as if nothing has happened. Then the context menu will reflect the context of the item that was last clicked on. Hence if I right-click on a background tab then the tab is first brought into foreground, then the menu is displayed, then if I choose "Reload" then the correct page reloads.
--> tabbed browser
Component: Toolbars → Tabbed Browser
Flags: blocking-firefox3.6? → blocking-firefox3.6-
QA Contact: toolbars → tabbed.browser
Component: Tabbed Browser → XUL
Product: Firefox → Core
QA Contact: tabbed.browser → xptoolkit.widgets
1. the problem is not limited to clicking on tabs. also clicking on other elements (url, forms and links in page, bookmarks) does not give them focus, when the tab context menu is open 2. url context menu also "eats" clicks in this manner 3. IMO comment #3, is unrelated and should be opened as a new bug
also back-forward context/drop down menu and url-history drop down menu, eat clicks
see also Bug 358864
This is the standard mode of operation for all contextual menus in Mac OS X, where I believe it is desired and expected by users: If one right-clicks an object, and then right-clicks it again, the contextual menu is re-opened. If one right-clicks and then left-clicks outside the contextual menu, the contextual menu is closed and left click is dropped. Note that, in Cocoa applications (but oddly not in Firefox), an application's user interface controls do not react to the hover state while a contextual menu is open (in the same application). As an aside, I suppose it might be a bug that Firefox doesn't drop the second click (at least on Mac OS X) in this situation for all controls (such as the close box), as well as that it doesn't likewise drop the hover event outside the context menu while the menu is open.
(In reply to comment #9) > This is the standard mode of operation for all contextual menus in Mac OS X, > where I believe it is desired and expected by users [...] Same on Linux
on the latest trunk (XP), it seems that the tab context menu no longer eats a click and focus to tab/url is transferred on first click however the url drop down menu, the url context menu, and the backward/forward drop down menu still eat a click the point is we must have consistency (at least per OS). Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b3pre) Gecko/20100721 Minefield/4.0b3pre ( .NET CLR 3.5.30729)
Fixed somehow somewhere: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:23.0) Gecko/20130504 Firefox/23.0 Bug 358864 still remains, but some of those might even desirable behaviors. :)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Kevin, you sure about this? It isn't working for me.
Hmm... probably a mistake on my part. First off, I tested on Vista 64bit w/ Firefox 64bit and not Windows XP. Sorry. Since it's listed as part of the "Core" I'm guessing this is a problem with some core component that is not used by Firefox now? I didn't even think about testing Seamonkey -- or anything beyond Firefox.
Confirmed on Vista: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20a1 Build: 20130504003001 It no longer affects Firefox (whatever they do differently I don't know), but still affects the "Core" it seems. Sorry for the mistake.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
You need to log in before you can comment on or make changes to this bug.