226525 - Right clicking on a tab and then left clicking on another tab does not activate the other tab

Status: REOPENED

(Core :: XUL, defect)

Description

[Kevin Ar18]

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:

Comment 1

[Ali Ebrahim]

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.

Comment 2

[Jesse Ruderman]

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.

Comment 3

[Andre Sihera]

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.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

--> tabbed browser

Comment 6

[eyal gruss]

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

Comment 7

[eyal gruss]

also back-forward context/drop down menu and url-history drop down menu, eat clicks

Comment 8

[eyal gruss]

see also  Bug 358864

Comment 9

[Dave Webber]

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.

Comment 10

[Michael Monreal [:micmon]]

(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

Comment 11

[eyal gruss]

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)

Comment 12

[Kevin Ar18]

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

Comment 13

[Tyler Downer [He/Him]]

Kevin, you sure about this? It isn't working for me.

Comment 14

[Kevin Ar18]

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.

Comment 15

[Kevin Ar18]

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.