Closed Bug 138860 Opened 23 years ago Closed 23 years ago

[rfe] Need Option for Picklist Links to Open in New Tab

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: mrmazda, Assigned: jag+mozilla)

Details

According to http://bugzilla.mozilla.org/show_bug.cgi?id=138809#c4, it is impractical or impossible to enable the right click menu to show "open in new tab" for items in a picklist. As a workaround, a UI pref could provide for every picklist URL to open in a new tab instead of the current window.
Resummarizing to reflect the actual RFE. The <select> has on onchange handler that sets window.location; the request is to redirect this to a new tab.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: [RFE] Need Option for Picklist Links to Open in New Tab → [RFE] Need Option for window.location.replace() to open in new tab.
Summary: [RFE] Need Option for window.location.replace() to open in new tab. → [RFE] Need Option for window.location.replace() (eg from <select> or picklist) to open in new tab.
If this was a new pref, it would have to be "open tabs for... left-clicking links". Is that what you want? Or do you want to be able to middle-click options in <select>s and make the event handler open a new tab?
Blocks: window-choice
I would think "every picklist URL to open in a new tab instead of the current window" would mean left click. I have no trackballs with middle buttons, so I don't know anything about the contents of any middle click menus.
Summary: [RFE] Need Option for window.location.replace() (eg from <select> or picklist) to open in new tab. → [rfe] pref to always open links in new windows
*** This bug has been marked as a duplicate of 15512 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
No longer blocks: window-choice
If you read the link in the original comment you will see this bug was spawned by bug 138809. A default behavior to open all links in new windows is definitely not being requested by this bug, so it is not a dupe of bug 15512. Default behavior should most definitely remain open link in current window. Reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: [rfe] pref to always open links in new windows → [rfe] pref to always open |window.location.replace() links in new windows (eg from <select> orpicklist) to open in new
Restoring original summary.
Summary: [rfe] pref to always open |window.location.replace() links in new windows (eg from <select> orpicklist) to open in new → [rfe] Need Option for Picklist Links to Open in New Tab
The original summary is nonsensical. There is no such thing as a "picklist link".....
At the top of http://mrccfl.com/ is a bunch of whatever the correct name for them might be, an example reason for the filing of this bug. Maybe form SELECT is the correct term to replace picklist? I'm not a programmer. Apparently bzbarsky@mit.edu use of the term in resummarizing was interpreted by jruderman@hmc.edu to mean all instances of window.location.replace() should redirect to new window.
> to mean all instances of window.location.replace() should > redirect to new window Correct. Since there is really no way to differentiate instances of window.location.replace(), they would either all need to go to a new tab/window or none would.
If there currently is no way to differentiate, maybe a way to do so should be futured.
<select onchange="act_like_link()"> function act_like_link { setTimeout("window.location.replace='http://here.we.go'", 0); } Now we _could_ tag every single function on a timeout with information about where it was triggered from.... but then the question arises: How are <select> elements priveleged over other content? What about: <body onmouseover="window.location.href='http://here.we.go'"> ? All Jesse pointed out is that it makes no sense to do this for (essentially) this one site unless we're going to try to solve the general problem....
Most of comment 13 is beyond my comprehension. I don't think http://mrccfl.com/ is an isolated case. I've seen similar menus on product documentation or parts lists or vendor sites. Those arrangements don't provide the benefit of a visited link's change in color from unvisited, so in searching for the one wanted the priors need to be opened in separate tabs or windows until narrowing down to the desired one, and the parent kept available via single click window select, e.g. its own tab, to facilitate the hunt. A parallel situation is that often when on a form I would like a submit button to cause a new tab to open, but I would not want that behavior to be non-optional.
It's not an isolated case, no. But to fix it, we would need to solve the much more general problem of always knowing exactly what user action triggered every single timer to fire or piece of code to be executed. Keeping track of this would introduce a fair bit of overhead... The form submit thing, being initiated by a user action instead of a script, is much more feasible (there's a separate bug on that).
See bug 138809 comment 6. There is no such thing as a "picklist link". The "picklist" (in html it's <select>) is a widget that can contain any text. Some pages choose to load a url when you select one of the items in the list (using javascript), but there is no easy way for Mozilla to know that a url should be loaded when selecting an item, nor is there an easy way to know which url to load. We could make this work given enough time and resources (I'm thinking in terms of months here), but I don't think this feature is worth that, so I'll mark this wontfix.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
mass-verifying Wontfix bugs. mail filter string for bugspam: Tursiopstruncatus
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.