283363 - Command-Click always opens the link in a tab, no matter what your preferences are set for.

Status: RESOLVED FIXED

(Camino Graveyard :: Preferences, defect)

Description

[Jo Rhett]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050222 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050222 Camino/0.8+

I don't know when it broke, but this build doesn't do the right thing for
command-click.  My preferences clearly say to open a new window and yet
command-click opens in a tab every time.  I hate tabs and would love to see a
preference to disable them entirely.  Right now I am forced to control-click and
choose the menu option to get a new window.

Reproducible: Always

Steps to Reproduce:
1. Hold down Command key and click on a link
2. Swear ;-0


Actual Results:  
I get a tab with the page I requested.

Expected Results:  
I should have gotten a new window.

Worked fine in 0.81 and various nightly builds in late January.  This is
probably my first nightly build from February, so it could have broken anytime
in the last few weeks.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

It seems to work properly in 2005022108 (v0.8+).

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #1)
> It seems to work properly in 2005022108 (v0.8+).

Scratch that.  With a fresh profile, I get the same behavior as comment 0 in
both the Feb 21 and Feb 23 nightlies.

The difference seems to be that in my existing profile's prefs.js I have the line
user_pref("browser.tabs.opentabfor.middleclick", false);

It's not in the prefs.js created by the "fresh profile creation mechanism", and
adding it stops makes "cmd-click link opens in new window" function again.

Interestingly, that pref is not in my existing profile's user.js (nor do I have
a mouse, so I don't think it would ever have been in my user.js [items added in
user.js get reflected back into prefs.js])...so I don't know how it ended up in
my existing profile's prefs.js.

Can you add that line to your user.js file (in your user's Library/Application
Support/Camino folder) and see if it also fixes the issue for you?

If so, that will give the Camino devs an idea of where to start looking for who
broke what when (sounds like someone confused the code for middle-click and
command-click?)

Confirming, though, since I can reproduce on a fresh profile.

Comment 3

[Mike Pinkerton (not reading bugmail)]

can we track down when this broke? prolly something to do with mucking with all
the pref panels.

Comment 4

[Simon Fraser [no longer active]]

I can't reproduce this. Command-click opens new windows if that's what the pref
is set to (and the foreground/background pref works as expected too).

Comment 5

[Jo Rhett]

Confirmation or refutation is useless without a build number.

It worked prior to this build (as reported in original bug report)

Comment 6

[Simon Fraser [no longer active]]

I was talking about my current development build, which is up-to-date with the
trunk.

Comment 7

[Jo Rhett]

Problem is still apparent in the latest nightly build (2005030308).  Preferences
say 

Command click on link: "Opens in a new window" is selected

New windows and tabs: "Load in the background" is not checked.

Yet command clicking on links opens them in tabs in the background.

Comment 8

[Jo Rhett]

Okay, I found a resolution.

Change the preferences to what they effectively are. (tabs and background) 
COMPLETELY close the browser.  Restart the browser and change them back.

Changing them without closing the browser and restarting it did not take effect.
 However, after restarting you can change the preferences either way and they
work fine.

Whatever causes it to ignore the preferences is likely good to affect a lot of
users during the 0.8 to 0.9 upgrade.

Comment 9

[Jo Rhett]

Sorry, somehow I overlooked the comments made by Smokey.  I never looked for
that line in my preferences when it wasn't working, but it is definitely there now.

Comment 10

[Mike Pinkerton (not reading bugmail)]

combo of bad hyatt code and prefs that got moved. fixed.