In Camino Tab Preferences, the option for "resusing" the last window when opening links from other applications is dangerous IMO. It is too easy to forget what window you had open, and if you have complex session state stored in that window have it clobbered accidentally when you click a link in IM etc. I would recommend removing this option (leaving it in your preferences plist for people who know what they're doing if some folk like the feature).
I definitely agree with this. It also lessens the preferences a bit more and makes them look cleaner. Mike?
Target Milestone: --- → Camino1.1
make it so.
Someone should file a follow-up bug on documenting the soon-to-be-hidden third option for this pref.
Created attachment 232825 [details] New Tabs.nib This does as described (no Tabs.mm changes necessary), but now that the reuse pref is gone, the whole radio matrix seems redundant. Are there really that many people who want cmd-click to open new windows, but want external links to open in new tabs (or visa versa)? I'm inclined to think we should just roll the whole matrix into the Cmd-click on link matrix. Thoughts?
How would you title that pref? Or does this become "Enable tabbed browsing" check box with hint text "Command () clicking on links and links from other applications (links opened from Mail, iChat, Address Book, etc.) will obey this setting" (and which takes the mixed state if you've toggled "other apps" to reuse)?
(In reply to comment #6) > Or does this become "Enable tabbed browsing" check box with hint text... That's basically what happens, yeah. This kind of merges with bug 346129 and bug 346128. We shouldn't have prefs that won't be used much. I think Mike needs to make this call though.
The other alternative is to make two checkboxes rather than one (or than one and a matrix like currently), one box per pref, with the second taking the mixed state when set to reuse.
I was actually picturing a two-button radio matrix, something like Cmd-click on links and external links: 0 open in new windows o open in new tabs However, the wording is obviously an issue (especially given that we can't have anywhere near that much text on the left side of the "divider." Additionally, using checkboxes instead lets us have a mixed state for the (4?) unexposed settings, so I think I'd be in favor of checkboxes over radios. Either way though, we should really wait until Mike says yay or nay before making specific implementation plans.
> Are there really that > many people who want cmd-click to open new windows, but want external links to > open in new tabs (or visa versa)? Is there anyone who doesn't? You people are crazy ;-)
i have cmd click open in a new tab and urls from an app open in a new window.
Comment on attachment 232825 [details] New Tabs.nib I'll take that as a no. Therefore, requesting review on just getting rid of "Reuse"
Comment on attachment 232825 [details] New Tabs.nib r=ardissone
what does this patch do again? there was so much discussion.
Comment on attachment 232825 [details] New Tabs.nib It just removes the "Reuse the frontmost window" setting from "Links from other applications", which is what we understood you wanted ;)
Comment on attachment 232825 [details] New Tabs.nib rs=pink
Attachment #232825 - Flags: superreview?(mikepinkerton) → superreview+
Checked in on trunk and 1.8branch
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Whiteboard: [needs checkin]
ARGHHHHHHH why did this happen? there was nothing ambiguous about the option. the worst that could happen if you had a "complex" state is that you would just click "back" in one of the tabs – there's no way to open multiple tabs from other apps anyway. how many "complaints" about this did we have? just make sure it's not a default option and be done with it... additionally, how are we treating the inconsistency between the hidden pref and radio grid? unlike checkboxes, which can now show a "mixed" state for user-modified prefs, this implementation has no way of showing what's actually in your prefs file and no way of finding out if the current state, as displayed, is actually what's in your prefs files.
Verified fixed in 1.8 branch and trunk
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1 → verified1.8.1
You need to log in before you can comment on or make changes to this bug.