User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040416 Camino/0.7+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040416 Camino/0.7+ I would like to be able to open new tabs in the background and new windows in the forground. Reproducible: Always Steps to Reproduce: 1. Camino->Preferences->Navigation->Tabbed Browsing Actual Results: It's possible to to either load both tabs and windows in the background or both in the foreground. It's impossible to load tabs in the background and windows in the foreground (like Safari). Expected Results: It should be possible to open new tabs in the background and new windows in the foreground (like Safari).

Confirming as an RFE. In fact, Camino is currently abusing the preferences, using browser.tabs.loadInBackground to control both tabs and windows. There doesn't appear to be a Moz pref to control what happens to new windows... the Firefox behavior seems to be to open new Windows in the foreground no matter what. I think that we should either do that, or make a new pref to control windows; controlling windows with the tab pref doesn't make sense.

*shrug*

I definatley would like to be able to loadnew tabs in the background and was suprised at the missing option when I went from the suite to firefox.

This would be confusing for most users as a GUI preference and won't be used enough to warrant a hidden pref, especially since the core pref doesn't exist. Resolving this as WONTFIX.

We decided back at the meet-up to switch to doing all windows in the foreground by default (and re-word the pref), but apparently I forgot to actually re-open this.

How does a user who uses only windows get new windows to load in the background in this new setup?

They wouldn't, which IIRC is true in Safari and Firefox as well. Do we have any evidence that anyone actually wants that behavior?

I know we still have a number of window-only users who appear periodically to complain about various things. I don't know the number of these users, but I also know we didn't turn on tabbed browsing by default for 1.5. I don't know how these window-only users of ours browse, but I do know that was the way I browsed before I adopted tabbed browsing; when opening most links, I wanted them to appear in background windows (just as today I want them in background tabs). FWIW, Safari at least allows the shift toggle to work; it's a bit sucky, but better than nothing for users who prefer to browse using only windows.

One great feature of Safari that I wish Firefox would steal is, Safari tells you in the status bar what will happen if you click on a link, and this changes depending on which modifier keys are being held down. For example, with my current setup: [no modifier] Go to "URL" [option key] Download "URL" [command key] Open "URL" in a new tab behind the current one [command+shift] Open "URL" in a new tab [cmd+option] Open "URL" in a new window behind the current window [cmd+opt+shift] Open "URL" in a new window The keyboard combinations are more complicated than most users can memorize, but having the description right there can help you learn the one or two combinations you use most often, and by mashing random buttons, find the combinations you don't remember. Of course, since Safari hides the status bar by default, most users are probably completely unaware that this feature exists. Oh well. :-)

That's not at all what this bug is about. If you want a feature in Firefox, please file a new bug against Firefox, don't hijack a completely different Camino bug.

My apologies; I wasn't paying attention and completely missed that this was a Camino bug and not a Firefox bug. That's what I get for reading bugmail in the middle of the night. Carry on!

Okay, I have a fix for this, which just needs new text for the pref (for this and bug 381356). I've tried a whole bunch of things, and this is what I eventually came up with: Links I open in new tabs: Open in the background I know we try to avoid first-person, but it was the only way reasonable way I came up with to capture the real basis we use for deciding when to apply the pref (namely, that the user explicitly caused the new tab).

Changes the pref to only apply to tabs. Shift continues to toggle window behavior, it just always defaults to foreground.

Just changes the wording of the pref accordingly, per comment 12 (also addressing bug 381356)

Comment on attachment 297496 [details] [diff] [review] fix First, a couple of words: I hate all of these Es, but it's what we do... and The load-in-background and load-in-tab/window/whatever stuff always seems like a tremendous mess to me. With that out of the way, let's hit the code! >+// Otherwise (if aSender doesn't respond to keyEquivalentModifierMask or aSender >+// is nil) it uses the current event's modifier flags. I don't think we need to waste time discussing the nil thing, since we don't give it special consideration in the code, and a nil object by definition doesn't respond to any selectors. >++ (BOOL)shouldLoadInBackgroundForDestination:(EOpenDestination)destination >+ sender:(id)aSender; Since you're adding an argument, you should follow the aArgument convention or (preferred) change aSender to sender - either way, but let's not mix. >+ BOOL loadInBackground = NO; >+ if (destination == eDestinationNewTab) { >+ loadInBackground = >+ [[PreferenceManager sharedInstance] getBooleanPref:"browser.tabs.loadInBackground" >+ withSuccess:NULL]; >+ } In some spots later on in your patch, for example, handleCommandReturn:, you used a ternary operator to accomplish roughly the same thing. Normally I'd prefer the ternary, but it is pretty wordy with all of those descriptive Cocoa calls in there. > if (modifiers & NSCommandKeyMask) { [...] > } > else >+ [self performSearch:mSearchBar inView:eDestinationCurrentView inBackground:NO]; Since one branch has the {braces}, the other one should too. I don't like the first-person wording in the nib (as you point out). Did we do a powwow to work on it yet? If not, we probably should. While you're editing this nib, you should fix bug 356204 for this pane.

(In reply to comment #15) > I don't like the first-person wording in the nib (as you point out). Did we do > a powwow to work on it yet? If not, we probably should. That wording got the coveted Smokey seal of approval, but we can certainly discuss and see if we can come up with something better.

I'm not fond of the first person either, but having tried at length to come up with something better in the past and having shot down all of Stuart's prior proposals in bug 381356 due to them not being accurate descriptions of what the pref controls, I think it's definitely our best bet so far.

Landed on trunk and MOZILLA_1_8_BRANCH, with fixes for mento's comments.