Filed on behalf of the forum poster because I think it's worth discussing this. Right now, when you have single-window mode ("Open tabs instead of windows for: Links that would open new windows") turned on and also "New windows and tabs: Load in the background", and you click a link that would open in a new window, you get a new foreground tab. Firefox, apparently, opens the same link in the background. Either we need to change the wording to make our behaviour clearer, or we need to change our behaviour to match the wording.
(In reply to comment #0) > Firefox, apparently, opens the same link in the background. Not as far as I can tell. Test case?
Yeah, I couldn't get Firefox 2 to work as claimed on those links in the phpBB thread there either. Smokey said he thinks this used to work, though.
Maybe it only worked in Firefox 1? I can't be that crazy, can I, but I swear it used to work, and it clearly doesn't in Fx1509, either.
(In reply to comment #3) > Maybe it only worked in Firefox 1? I can't be that crazy, can I, but I swear > it used to work, and it clearly doesn't in Fx1509, either. That whole thing (part of the single window mode rewrite) changed between Gecko 1.7 (Fx 1.0) and Gecko 1.8 (Fx 1.5) - which broke SWM in Camino branch+trunk for a while. (I find that behaviour (open in a new tab that jumps to the front) crazily annoying, and have set my pref to open the 'target' link to open in the same tab. If I want it in a new tab (aka, reading later), I just command-click the link and that goes in the background as expected.)
I'm not entirely convinced that what we're doing is wrong. When you single click a link it's because you want to see it immediately, regardless of prefs. With jumpback I don't see this as a problem.
I'm not entirely convinced that our current behavior is wrong, either, but it's certainly tricky. You're normal-clicking, to which the load in bg pref doesn't apply, but at the same time, you're normal-clicking and therefore don't expect to *get* a new tab/window at all. When you then get a new tab, well, I don't know...you still want to read it, I guess? In my case, I've ended up doing the same thing as philippe; set SWM to reuse via about:config, so I don't get new tabs at all in scenarios like this, and then always use cmd-click when I want new tabs (and shift to toggle load in bg on/off and jumpback, depending on what I expect to do with said new tab—read it later, or take a quick glance and go back to what I was reading).
First off, in Firefox 2.0.3 (Mac and Linux at least), the settings "new pages should be opened in a new tab" and unchecked "when i open a link in a new tab, switch to it immediately" lead to the desired behavior (well, desired by some of us I guess). More to the point... let me ask you all two questions: 1) Would you like links that open new windows to open new windows or in new tabs? 2) Would you like these new windows or tabs to open in the background? If your answers were tabs and yes, would you expect to need to command-click to have the new tabs open in the background?? That's what the pref pane in camino asks, in that order. If consensus is that "normal clicking" is what we're doing, then the text of the pane needs to be fixed.
I'm with Smokey: it's a normal click, and the expectation for a normal click is that you want to follow the link as primary navigation; if you don't want to switch contexts, use Command-click. I think we should WONTFIX this and address the pref wording in bug 381356.
How about this? In the pref pane for tabs: open tabs instead of windows for: [ ] links opened with cmd-click [ ] in bg [ ] links opened by other apps [ ] in bg [ ] links that would open new wins [ ] in bg and let users have control and choice. It seems clear that there are two opinions on this, why should either one be forced?
I third Smokey/Stuart's opinion here. The current behavior is desired navigational flow, the solution is wording. Marking WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.