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

REOPENED
Unassigned

Status

()

--
minor
REOPENED
15 years ago
5 years ago

People

(Reporter: kevinar18, Unassigned)

Tracking

(Blocks: 1 bug, {polish})

Trunk
x86
Windows XP
polish
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Advo])

(Reporter)

Description

15 years ago
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

15 years ago
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

Comment 2

15 years ago
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.

Updated

13 years ago
Assignee: hyatt → nobody
QA Contact: bugzilla → toolbars

Comment 3

13 years ago
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.

Updated

13 years ago
Version: unspecified → Trunk

Updated

11 years ago
Blocks: 321023

Updated

11 years ago
Duplicate of this bug: 252026

Updated

9 years ago
Flags: blocking-firefox3.6?
--> tabbed browser
Component: Toolbars → Tabbed Browser
Flags: blocking-firefox3.6? → blocking-firefox3.6-
Keywords: polish
QA Contact: toolbars → tabbed.browser

Updated

9 years ago
Component: Tabbed Browser → XUL
Flags: blocking-firefox3.6-
Product: Firefox → Core
QA Contact: tabbed.browser → xptoolkit.widgets

Comment 6

9 years ago
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

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

Comment 8

9 years ago
see also  Bug 358864

Updated

8 years ago
Blocks: 565510

Comment 9

8 years ago
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

Comment 11

8 years ago
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)

Updated

6 years ago
Whiteboard: [Advo]
(Reporter)

Comment 12

5 years ago
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
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
Kevin, you sure about this? It isn't working for me.
(Reporter)

Comment 14

5 years ago
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.
(Reporter)

Comment 15

5 years ago
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.