Open Bug 581876 Opened 14 years ago Updated 2 months ago

Click-through with middle button is not yet sane (per fixes from bug 392188)

Categories

(Core :: Widget: Cocoa, defect)

All
macOS
defect

Tracking

()

UNCONFIRMED

People

(Reporter: nfagerlund, Unassigned)

References

Details

Attachments

(1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100725 Minefield/4.0b3pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100725 Minefield/4.0b3pre

Hurray, click-through behavior is getting saned up! (I noticed. It is really nice.) 

The middle mouse button (if you have one) still acts crazy, though, and Command-click functions almost (but not quite) identically. Here are the ways it contradicts Markus Stange's description of desired behavior from bug 392188, comment 38: 

* Middle-clicking (or Cmd-clicking) anywhere in a background window for any reason _while Firefox is not the active application_ will not activate Firefox. (Wrong because: any action attempted with a normal click will, win or fail, focus the clicked window and activate Firefox; middle/Cmd-click should match this baseline behavior.)
* Interestingly, middle- or Cmd-clicking in a background window while Firefox _is_ the active application will bring that window to the front... but _only_ if you make that click somewhere where it won't have any other effect (see below). If you middle/Cmd-click for effect in a background window, you'll get the effect without activating the window. (Wrong because: this is completely crazypants.)
* Similarly but even weirder, middle- or Cmd-clicking in a background Firefox window while Firefox ISN'T active will bring that window into second place on the OS's Z-axis, i.e. move it in front of every window (including windows belonging to the active application) _except_ for the currently active window. Again, this _only_ happens if the click did not cause any other effect. (Wrong because: well, um, huh.)
* Middle/Cmd-clicking a link in a background window's content area will open that link in a new tab in said window. This behavior is the same regardless of the currently active application. (Wrong because: per the new rules, content must reject click-through.) 
* Middle-clicking (NOT Cmd-clicking) a tab in a background window will close said tab. This behavior is the same regardless of the currently active application. (Wrong because: per the new rules, chrome should reject any click-through which would have a destructive effect.) 
* Cmd-clicking (NOT middle-clicking) a tab in a background window will focus said tab in the window (without focusing the window). This behavior is the same regardless of the currently active application. (Wrong because: Chrome should accept non-destructive click-through effects _and_ focus the window; this only accepts the effect.)
* Cmd-clicking (NOT middle-clicking) a tab close button in a background window will briefly focus said tab, close said tab, and then focus the tab directly to said tab's right. (Wrong because: Chrome should reject destructive click-through, plus this weird focus-close-refocus behavior is completely different from what happens when you click a close tab button in a focused window, what happens when you close a tab with middle-click, and! even what happens when you Cmd-click a close tab button [never mind the question of why one would even do that] in a focused window. This is the ONLY way I know of to get this behavior.)
* Middle/Cmd-clicking a bookmarks toolbar button in a background window while Firefox is _NOT_ active will do zilch. (Wrong because: Chrome should accept clickthrough. This is also the one exception I can find to the way middle/Cmd-clicking while Firefox is not active will shuffle the OS Z-axis order.) The behavior of bookmark items in the Places manager and the bookmarks sidebar is nearly identical, except that it'll grant selection to the clicked item. 
* Middle/Cmd-clicking a bookmarks toolbar button in a background window while Firefox _IS_ active will open the linked page at the end of the currently active window's tab order. (Wrong because: chrome should affect the window it belongs to, not some other completely unrelated window.) Again, the behavior of bookmark items in the Places manager and the bookmarks sidebar is nearly identical. 
* Middle/Cmd-clicking the Home button in a background window (regardless of the active application) will open the home page at the end of said window's tab order. (THIS IS COMPLETELY CORRECT.)
* Middle/Cmd-clicking the back or forward button (or any menu item in the back/forward right-click menu) in a background window will open the relevant historical page in the next slot in the normal new tab order in either the currently active window (if Firefox is active) or the most recently active window (if Firefox is not active). Note that this will not be tricked by futzing with the OS Z-axis per that earlier bullet-point: it will correctly remember which window was last active. Middle/Cmd-clicking the reload button in a background window will open a copy of the page in that window's currently active tab per this behavior. (Wrong because: chrome should affect the window it belongs to, not some other completely unrelated window.)
* Middle/Cmd-clicking the search bar (magnifying glass) button in a background window will open a search results page for the currently entered query at the end of the tab order of either the currently active or most recently active window, depending on whether Firefox is active. This is sort of the happy medium between the behavior of the home button, the back/forward button items, and the bookmark toolbar/manager items. (Wrong because: chrome should affect the window it belongs to, not some other completely unrelated window.)
* Middle/Cmd-clicking an RSS icon in the location bar will do almost the same thing as the search bar button does, except that it'll behave correctly (focus the window it belongs to and act on said window) if Firefox is active; it'll only misbehave if Firefox isn't the active application. 

I think that's all of it! Woof. 

Reproducible: Always

Steps to Reproduce:
See table of results above.
Actual Results:  
Middle/Cmd-click-through is completely idiosyncratic and non-systematic. 

Expected Results:  
Middle/Cmd-click-through abides by rules similar to those governing normal click-through.
Depends on: 392188
Version: unspecified → Trunk
> Middle/Cmd-clicking the reload button in a background window will open a copy of the page in that window's currently active tab per this behavior. 

(Whoops, sorry, said that wrong: It'll open a copy in the next slot in the normal new tab order in the current or most recent window, just like the back/forward items I grouped it with.)
Depends on: 612480
Severity: normal → S3
Attachment #9383858 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: