Talk:Link Targeting

Comments from Jesse:

I disagree with "Set the window restrict option to 3 (so that when the user chooses to have tabs opened instead of windows, windows with specific sizing parameters are not opened in oddly sized tabs)", because it will make the option not work for a huge number of sites. "Set the re-select-on-close behavior to select the previously viewed tab, when tabs opened by document or external sources are closed." seems strange and inconsistent. I agree with most of the rest.

Isn't it late in the Firefox 1.5 cycle to make these kinds of changes?

Comments from beltzner:

Jesse, can you point out a couple of sites that will break if we set the default force-tab behaviour to option 3?

There's some discussion about the re-select-on-close behavour in bug 279574. mconnor has convinced me that the inconsistent behaviour might be troubling, especially since it requires that users remember how various tabs got opened, but I think it would be interesting to get it to a point where we could do some testing on it to see what users are expecting and how we can match those expectations.

And yes, it is late in the cycle (as mentioned in the aforementioned bug) to be exploring this for 1.5, although some of Ben's suggestions in here (ie: rewording of options, removing the "over existing tab" option, and defaulting the force new windows into tabs to restriction level 3) are low-risk and probably the right thing to do for 1.5

Bug numbers

1. Set all link targeting behavior to open new windows where windows are requested, regardless of source
2. Set the window restrict option to 2 (so that when the user chooses to have tabs opened instead of windows, windows with specific sizing parameters are not opened in oddly sized tabs) (https://bugzilla.mozilla.org/show_bug.cgi?id=266299 - WONTFIX!)
3. Set the re-select-on-close behavior to select the previously viewed tab, when tabs opened by document or external sources are closed. (https://bugzilla.mozilla.org/show_bug.cgi?id=279574)
4. Combine all targeting options into a single boolean value, controlled by two radio buttons (see Options section above)
5. Re-word the "Select new tabs opened from links" preference so that it's more understandable. (https://bugzilla.mozilla.org/show_bug.cgi?id=111842 - SeaMonkey)

More comments from Jesse

One example of a page that behaves badly when browser.link.open_newwindow.restriction is set to 2 is http://weblogs.mozillazine.org/asa/. The trackback links open in a new window for no good reason, and they have width+height set. That's not completely Asa's fault; it's part of the default Movable Type template set.

More comments from Beltzner

I don't know if that's for "no good reason"; the default MT templates for trackback actually look like the templates for comments. Asa's modified that slightly so it doesn't seem as sensible in its own window.

More comments from Jesse

The default Movable Type template makes both the "comments" and "trackback" links open in new (sized) windows. I stand by my assertion that it does so "for no good reason".

More comments from Beltzner

That's an aesthetic preference you should really take up with Moveable Type's template designers. They intend (in the v2.6661 and 3.0 templates, anyway) for these windows to be popup windows, and the templates are designed as such. Accordingly, the restriction level would show them as popups. To me, that's seems very much like the right thing to do, regardless of one's preference about whether or not it's a good use of a sized window or not.

More comments from Jesse

When I check "Force links that open in new windows to open in: a new tab", I expect it to apply to all such links, not a random-seeming subset of those links. I think the same is true for most users who check that option.

Comments from Marco

It would be very good if we had all features found on the Quicktabpref extension. I like letting the sized pop-ups to use a new window. Please check it out!

Comments from Boris

I should point out that the options for forcing _anything_ into new tabs instead of new windows are not very well tested. We have various issues when those prefs are set (eg with window.close on a tab quitting the app when it should not, window targeting not working correctly in may cases (a general problem with tabs, but exacerbated by putting named targets in new tabs, where they cannot be targeted), etc).

So I think that hiding the UI as we did in Firefox 1.0 is actually the best option, assuming we're not willing to disable the prefs altogether.

Web and Client Applications

There is a big difference between web and client Applications, the web application allready lives in a browser window, while the client application does not.

It's perfectly sensible to open a link from gmail in a new tab next to the tab I'm currently using. Opening a link form an IM in a tab next to gmail is confusing.

When browsing I'm using multible windows with multible tabs. Each window contains a set of related tabs. A link form a client application is probably not related to any page already open, but a link form a web application is related to the web applicaiton itself.

Markus Schmaus 19:09, 23 Feb 2006 (PST)

But I dont like tabs.

A long time ago, when tabbing was new, I could select an option on the edit/preferences/tabs page to select "open link in new window" with my middle mouse buton.

I would like that back. -- please/aTdHvAaNnKcSe

PS. I also would like simple things like the emacs type editing on the <TEXTAREA> not to require obscure test to be edited into an obscure file. I almost feel bad saying this. But it not like the httpd.conf file with 100s of great things I can uncomment to get access to.

PSS I was not sure where to put any if this... Strcat 07:49, 8 August 2006 (PDT)