It would be nice to be able to execute a command line which would open a url in a new tab on the topmost browser window. If no windows are opened the url would be opened just as it is now. Similar to the target=_blank request in bug 103823. If this is done just slap me and tell me the paramaters.
do we have a tracker for tabbed browser enhancements?
Yes. It's called the Tabbed Browser bugzilla component. ccing blizzard since this sounds like xremote stuff.
No dupes found. Marking NEW.
This should be part of the pref to switch between normal and tabbed browsing. We can't expect AIM to guess whether you want to open a link in a new window or in a tab.
What about the implementation of target="_tab" ? This could open a new tab and if you're browsing with another browser it opens just a new window. Greetings, Captain / Austria
*** Bug 105409 has been marked as a duplicate of this bug. ***
>What about the implementation of target="_tab" ? This may be a good idea but it is covered in Bug 105409, which has erroneously been marked as a duplicate of this one. This bug deals specifically with opening a new tab from the command line. This will allow url's from other programs to be associated with Mozilla and yet open in a new tab instead of a new window.
IMHO target="_tab" is not a good idea - this is not HTML standard. Page creators does not care if user prefers "new tabs" or "new windows", and users want control this!
However the command-line option is specified, this would be a great feature.
*** Bug 105891 has been marked as a duplicate of this bug. ***
The command-line option would be great, because it would allow for things like having a mail client other than Messenger (e.g., Pegasus Mail, or Eudora, or whatever) launch URLs (from those displayed in email messages) into new tabs -- a big win. Another possible way to achieve that would be to have a user preference to load URLs passed in from other apps in new tabs, but the commandline option is interesting in itself because it would allow one app to utilise one behavior and another app to do it the other way. For example, I might want URLs launched from Pegasus Mail to load in new windows, but I might want URLs launched from a desktop shortcut to use a new tab. Or vice versa.
spam: set your filter for "SeverusSnape" to avoid the influx of bugmail changing QA contact of open tabbed browser bugs from blake to me. if this bug requires a reassignment, however, feel free to change it!
*** Bug 114406 has been marked as a duplicate of this bug. ***
Reassigning to new component owner.
-> future, helpwanted
I think there should simply be a preference entry looking like that: [_] Open URL in a new tab instead of in a new window [_] Open file in a new tab instead of in a new window The first is the case that applies when Mozilla is started with the -url paramter (e.g. if you click onto an URL in an external application). If the option is not checked, Mozilla will open a new Window and load the page, the same way it's doing it now. If the option is checked, Mozilla should take the latest window (the one you opened most recently), create a new tab there and load the page in that new tab. If Mozilla can't decide which one is the latest window (maybe that's not possible), it may take the first window that it finds of the currently opened ones, create a new tab and load the page there, but the latest one would be preferable, I guess. This option applies to all URLs that are displayed within a browser window (HTTP, FTP, etc.) The same behavior is expected from the second option, but the second option only applies if you open a file associated with Mozilla (e.g. HTML, XML, as well as pictures if you have associated them with Mozilla). Both options should be located under: Preferences -> Navigator -> Tabbed Browsing There's an extension to IE, that enables tabs within IE and this extension seems to work like described above for new URLs.
*** Bug 148988 has been marked as a duplicate of this bug. ***
Hmmm.... Is there anything going on with this?
Kirsch: > Hmmm.... Is there anything going on with this? Generally when something is targeted for Future, that means little or nothing is currently being done with it yet. The assignee may have other bugs that are more urgent. The helpwanted keyword indicates that contributions from others are welcome, if anyone else has time to work on it before the assignee.
Now that bug 116653 is fixed, this bug and bug 111539 could both be fixed by simply implementing -remote on Windows (and Mac?) OSes. I don't quite understand why this works for X systems but not for others.
This looks like bug 121969. That bug has 38 votes to this bug's 13. Both bugs call for essentially the same thing: a pref that determines whether a new tab or a new window is opened for URLs called by an external app (be that app a command line or a GUI program). Duping to bug 121969.
Duping *** This bug has been marked as a duplicate of 121969 ***
No. This bug is about a command-line option to open in a new tab, regardless of the pref settings.
Since Linux gets this via mozilla -remote "openurl(http://www.mozilla.org, new-tab)" is there really a lot of arguing and hand wringing about the Right Thing? :)
i don't think a commandline switch is a good idea. i have a draft of a discussion on this point if people are interested in it. being able to configure your browser to accept external links and open them in new tabs is one thing (reasonable), allowing your browser to be inconsistently used by a wide range of hard to configure external applications is another (...).
Granted, it opens a window for potential :abuse: but this potential is far below the usefulness of this feature. It was implemented on Linux due to the huge number of developers on Linux desiring an easier way to open links in new tabs. And seeing as how we _already_ have it in the tree for one OS, there's little valid argument to implementing it on other OSes.
There is a command line switch available that does just what the reporter wants (and can do more :-), but it is Unix only: http://www.mozilla.org/unix/remote.html If I understand this bug correctly, it is about implementing something like this on all supported platforms, right?
Well, when the bug was reported, there was no "new-tab" option yet.
Stephan: As I said in comment #20, implementing -remote for all platforms would resolve this bug and the similar one for new windows.
It seems the primary argument against this is that the user should be in control of thier interface, and they can have the option to enable middle-clicking to create tabs. Well, that is just fine and dandy, _when it is a normal link_. What about forms? I middle click on a submit button and *voila*... wait no. All that does is cause it to gain focus. I believe the best way is to introduce the "_tab" value of the target attribute, and add a preference, which will decide wether it is treated as intentended, by opening in a tab, or treated as "_blank". Many website have messages like "This site requires Internet Explorer", and while this is rediculous, the option should be available, atleast then a website can have the option. In a forum, a user could then turn on an option such as "Open threads in new tabs (requires Mozilla ...)". I'm all for user choice, but right now, I (as a user) don't have a choice in some cases. Cheers, ~nog_lorp
(In reply to comment #8) > IMHO target="_tab" is not a good idea - this is not HTML standard. Page > creators > does not care if user prefers "new tabs" or "new windows", and users want > control this! > Rubbish! I need control of this to improve usability of a web based admin console. I need several tabs to be kept in sync. I need to open one URL - the console - and then have that open several other tabs and keep them in sync as I navigate the console. (not all uses of browsers are for just perusing the Interweb ;o)
(In reply to comment #29) > Stephan: > As I said in comment #20, implementing -remote for all platforms would resolve > this bug and the similar one for new windows. -remote is working for me on Windows with SeaMonkey 2 nightlies (don't know since when). If someone can confirm the same for Mac, that might qualify for closing this bug.
Since the fix for bug 479600 there's -new-tab so this is definitely done. However -remote might have fixed this bug prior to that so I won't mark this as a duplicate but just WORKSFORME.