Closed
Bug 227241
Opened 21 years ago
Closed 20 years ago
Open new windows only upon explicit instruction (Single Window Mode) (open new-window links in tabs instead)
Categories
(Firefox :: Tabbed Browser, enhancement)
Firefox
Tabbed Browser
Tracking
()
VERIFIED
DUPLICATE
of bug 172962
People
(Reporter: mozilla, Assigned: bugzilla)
References
Details
Attachments
(1 file)
21.79 KB,
image/jpeg
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.5) Gecko/20031007 Firebird/0.7 Firebird should have the option of a single window mode (à la TBE) built in. Firebird version of bug 103843 (?) Reproducible: Always Steps to Reproduce:
Comment 1•21 years ago
|
||
I've heard "single window mode" mean two features: A) Windows that the web page opens open in a new tab. B) A, plus Ctrl+N opens a new tab instead of a new window, and all "Open ... in New Window" commands are removed. I am in favor of adding (A), but I am against adding (B) as a single checkbox.
Reporter | ||
Comment 2•21 years ago
|
||
TBE implements Single Window mode in one of two ways (configurable by the user): 1. only ever use one window (A & B) 2. open new windows only upon explicit instruction (A) My original suggestion was for Only ever use one window. However, I think the other option would be better, assuming it's do-able, and not as buggy as TBE's implementation.
related to bug 189313?
Comment 4•21 years ago
|
||
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: RFE: Single Window Mode for Firebird → Single Window Mode for Firebird
Updated•21 years ago
|
Summary: Single Window Mode for Firebird → Open new windows only upon explicit instruction (Single Window Mode)
Comment 5•21 years ago
|
||
this has to be somewhere already, I know this is planned...
I don't recall seeing anything in the roadmap nor a confirmation from any of the devs. This is the most requested TBE feature, though.
Comment 7•21 years ago
|
||
Re comment 6: Dave Hyatt, the Firebird module owner, has said in http://forums.mozillazine.org/viewtopic.php?p=144580#144580 : As for TBE, there are some features that we'd like to implement, but in some cases TBE has implementations that aren't desirable, e.g., the way it forces open windows into new tabs. My understanding is that it actually lets the window open and then it shoves it into a tab and closes the window (this also severs the window.opener connection that is supposed to exist between the two windows). We want to fix that at the C++ level and really make the initial window open right in a new tab. Some tab features that we would like to see incorporated into Firebird (patches welcome): (1) Ability to drag/drop to reorder tabs (2) Ability to force windows into new tabs always (hard, anything that just hacks JS is inadequate) (3) Ability to drag a tab out of the tab strip and drop it into another tab strip or to drop it on the desktop and have a new window get made Features that we will not accept: Tons of prefs for tabs just because you don't like our defaults (e.g., where tabs open, where tabs close, close boxes on tabs, etc. etc.). Adding a bunch of geeky configurability options is perfect for an extension.
Javascript popup windows should probably be allowed to open in a new window or else the graphics and text would be skewed.
Reporter | ||
Comment 9•21 years ago
|
||
“Javascript popup windows should probably be allowed to open in a new window or else the graphics and text would be skewed.” Clicking a javascript popup link isn't an explicit instruction to open a new window. Besides, most JS popups look OK in tabs.
http://forums.mozillazine.org/viewtopic.php?t=37895 This is the thread where a signficiant portion of the MozillaZine populace voted for the features that they wanted to have in the core from TBE. Single window mode topped the list. What milestone is this targeted for? Is it just a matter of writing a diff that adds single window mode to the core, or will it take longer?
Comment 11•21 years ago
|
||
The goal is to implement this in C++, not javascript, so that its faster/smoother. If someone wants to write a patch for this, I'm sure it will get some attention. Keep in mind the requirement means it is part of the backend, not in the XUL frontend, so porting stuff out of TBE won't cut it. If this is shared with Seamonkey, as long as it defaults off it won't really matter, and those who'd want it in Seamonkey could always use the hidden pref.
QA Contact: mconnor
Comment 12•21 years ago
|
||
Re: comment 8 and comment 9 Ideally, javascript new windows ought to be handled the way TBE handles them when using setting 2 as described in comment 2. If the window it would open is a full, normal window (i.e. just a plain window.open() call) it makes it a tab. If there's a window size specified, it's best to open the window as specified by the call.
Comment 13•21 years ago
|
||
There are three options in TBE and they're probably there for a reason. I prefer option 3, always only use one window. Crazy Browser, the first tabbed browser that I used, offered the option for everything in one window or the ability to use more than one window.
Reporter | ||
Comment 14•21 years ago
|
||
Having javascripts pop up new windows should be optional; I prefer new windows to open in tabs, regardless of their size - a bit of whitespace around the content usually does no harm.
Comment 15•21 years ago
|
||
*** Bug 232955 has been marked as a duplicate of this bug. ***
Comment 16•21 years ago
|
||
Re: Comment #14 and other JS open in tab comments... Simple workaround to avoid pages being skewed or stretched to the full size of the tabbed window is to set a containing div with explicit width and height values that the JavaScript link requested. Setting a border around this div, an overflow value of auto and centering it within the screen would essentially mimmick the hehavior of a popup, but within the framework of a tabbed browser.
Comment 17•21 years ago
|
||
At the moment, TBE option #3, everything in tabs stretches things out but I've been using that mode for a long time and it seems fine to me. I suppose that there may be problems for some popups that rely on the screen size instead of fixed pixel positions but I've never run into one of those. Of course I normally see very few popups except the ones that I want.
Reporter | ||
Comment 18•21 years ago
|
||
(In reply to comment #16) I like this idea. However, this throws up the problem of what to do if the website uses links with target attributes. Should we (a) ignore a target attribute pointing to an already-open window and open another tab; (b) open that link in the existing tab, without the containing div; or (c) open it in the containing div? If (c), which seems to make the most sense, how do we go about id-ing the div as if it were a frame? Or should we use a frame instead (which may or may not be do-able whilst complying with standards - I believe iframe's deprecated)? Maybe XUL could come into it, to restrict the size of the popped-up tab to the size specified by the javascript, greying out the rest. Actually, I quite like that idea. :) Just thinking in type...
Comment 19•21 years ago
|
||
RE: Comment #18, As long as the correct tab is identified by the core code this should be simple (well, simple logic anyway)... 1. User clicks a JavaScript link to spawn a popup window, which is loaded in a tab. The following properties are obtained by the core code: - Height & Width - How to handle overflow - i.e. scrolling or not - ID or name of the window. 2. Height & Width are used to create a div, as is the overflow. ID/name of the window is added to an array, referencing which tab is used for that ID. 3a. User clicks another link which targets the previously spawned window, which we are handling in a tab. Core code obtains the target of the link and compares to those in array. If a suitable tab is found, Firebird reads HTML content (if any) at the href (assuming it exists) and switches the old containing div contents for new... The HTML would then render normally. 3b. If the href references to an image, this should be shown in an <img> tag within the previously created containing div. I dont know how practical or reasonable that is, though. I would assume that it'd be possible to use frames on a "lower level" such as this... as the behavior of these frames will be known by the development team, and AFAIK not an issue with accessibility.
Comment 20•21 years ago
|
||
Actually it would be extremely nice if there was a Closebutton in every tab, instead of having to move your mouse to the right corner which, since most people use mousescroll, is annoying. There are also more positive things with having a Closebutton in each tab, for example, you may want to close alot of tabs in one instance. Without having a Closebutton in each tab you would have to first select the tab, then move your mouse to the right side of the windows and close, which is quite annoying, especially for me working with many sites on the same time.
Comment 21•21 years ago
|
||
That's bug 108938 (wontfix).
Comment 22•21 years ago
|
||
(In reply to comment #21) > That's bug 108938 (wontfix). Why not let people decide for themselves whether this is a good or bad feature, I think there are alot of people out there who wants this, and if it's a setting you could always deactivate it if you don't like it?
Comment 23•21 years ago
|
||
Because there's an extension that already offers that functionality. It's in TBE and also there's a standalone extension for that single purpose only.
Comment 24•21 years ago
|
||
(In reply to comment #21) > That's bug 108938 (wontfix). Why not let people decide for themselves whether this is a good or bad feature, I think there are alot of people out there who wants this, and if it's a setting you could always deactivate it if you don't like it?(In reply to comment #23) > Because there's an extension that already offers that functionality. It's in TBE > and also there's a standalone extension for that single purpose only. The advantages of having the function in the core is, possible speed advantage/better integration?, no risk of extention colliding with another extension and you wouldn't have to worry about extension not working with new builds/slow updating.
Comment 25•21 years ago
|
||
1) Stop spamming this bug, go file a new one or post in the "WONTFIX" bug, this has nothing to do with what you want. 2) It would _never_ be implemented as a "core" feature, simply because the entire user interface is designed in JavaScript, XUL etc, so your speed arguement is entirely void. It can be achieved with a small piece of CSS placed in your userChrome.css file, or by installing one of the two mentioned extensions.
Comment 26•21 years ago
|
||
Sorry to spam this bug some more, but that idea of using CSS in userChrome.css to put a closebox in tabs sounds interesting. Do you know the code that will do this?
Comment 27•21 years ago
|
||
Seems I was wrong about userChrome.css, but there's an extension which does more or less what you want here: http://downloads.us-east3.mozdev.org/clav/tabx/tabx.xpi It could be better, but it has the functionality you desire.
Reporter | ||
Comment 28•21 years ago
|
||
Just a note - some people on netscape.public.mozilla.wishlist are asking for this to be "fixed", i.e. it's currently broken. I suggest upgrading severity to minor.
Comment 29•21 years ago
|
||
severity != priority, so that's invalid. Just because someone thinks there is such a function doesn't mean its broken.
Reporter | ||
Comment 30•20 years ago
|
||
(In reply to comment #29) > severity != priority, so that's invalid. Just because someone thinks there is > such a function doesn't mean its broken. It does mean that advertising Firefox as a "tabbed browser" might be misleading... but that's a different issue.
Comment 31•20 years ago
|
||
why? it is a tabbed browser, just because it doesn't have as much control as it might have doesn't mean its not a tabbed browser.
Comment 32•20 years ago
|
||
I too wanted a UI more like CrazyBrowser's single-window tabbed browsing. With a bit of crude hacking on the JS files, this can be partially achieved, as detailed below. Two comments though: * This isn't and wasn't intended to be an elegant or fast C++ solution, just a quick-and-dirty JS bandaid until there is some actual code for the C++ solution. * It doesn't fix bug 103843 or bug 105547 (i.e. JavaScript and target windows still open in new windows). I'm not sure how to fix these, or even if they can readily be fixed with JS. ======================================================== * Do not update the main window's title with the current tab's page title - doesn't makes much sense to do this in a single window mode. need to extract toolkit.jar then edit chrome\toolkit\content\global\bindings\tabbrowser.xml: <method name="updateTitlebar"> <body> <![CDATA[ + return; var newTitle = ""; var docTitle; if (this.docShell.contentViewer) docTitle = this.contentTitle; [Note - works most of the time, but very occasionally the titlebar gets updated somehow, so must have another code path somewhere that allows this ] ======================================================== * "Open in new window" should open in tabs, not in a new window [Need to unzip browser.jar in the "chrome" directory, and edit "browser\content\browser\contentAreaUtils.js" like so:] function openNewWindowWith(href, linkNode, securityCheck) { + try { + openNewTabWith(href, linkNode, null, securityCheck); + return; + } + catch(ex) { + } if (securityCheck) urlSecurityCheck(href, document); [More complete version would check a pref, like so] + // should we open it in a new tab instead? + var loadInNewWindow = false; + try { + loadInNewWindow = prefSvc.getBoolPref("browser.singleWindowMode"); + if (loadInNewWindow) { + openNewTabWith(href, linkNode, null, securityCheck); + return; + } + } + catch(ex) { + } Effect - the "open in new window" right-click menu now happen in new tabs, but ctrl-N and the file->new window still give new windows ======================================================== * CTRL-N should open a new tab, not a new window, as should File->New Window edit chrome\browser\content\browser\browser.xul from browser.jar : <key id="key_newNavigator" key="&newNavigatorCmd.key;" - command="cmd_newNavigator" + command="cmd_newNavigatorTab" modifiers="accel"/> <key id="key_newNavigatorTab" key="&tabCmd.commandkey;" modifiers="accel" command="cmd_newNavigatorTab"/> ... and.... <menuitem label="&newNavigatorCmd.label;" accesskey="&newNavigatorCmd.accesskey;" key="key_newNavigator" - command="cmd_newNavigator"/> + command="cmd_newNavigatorTab"/> <menuitem command="cmd_newNavigatorTab" key="key_newNavigatorTab" label="&tabCmd.label;" accesskey="&tabCmd.accesskey;"/> [DONE - still have unneeded "New window" elements from the UI that could/should be removed, e.g. from the File menu] ======================================================== * Closing last tab does NOT close the window, but instead adds a new one on "about:blank" - with a single window mode, want the main window to stick around, and want a way of closing that main window that is NOT the same as the way of closing a single tab. from browser.jar, edit chrome\browser\content\browser\browser.js ~line 798: function BrowserCloseTabOrWindow() { if (gBrowser.localName == 'tabbrowser' && gBrowser.mTabContainer.childNodes.length > 1) { // Just close up a tab. gBrowser.removeCurrentTab(); return; } + if (gBrowser.localName == 'tabbrowser' && gBrowser.mTabContainer.childNodes.length == 1) { + // If this is the last tab, open "about:blank" tab, and don't close the window + // gBrowser.addTab('about:blank'); // opens a new tab, closes current + // gBrowser.removeCurrentTab(); // but causes an ugly brief flashing effect + loadURI('about:blank', null); // still leaves back & forward buttons active though + // UpdateBackForwardButtons(); // doesn't disable forward and back + return; + } BrowserCloseWindow(); } [Done] ======================================================== * Want the word "Blank" to show in tab title, instead of "(Untitled)", as per other tabbed browsers [need to extract toolkit.jar] then edit F:\Moz-Firefox-0.8\chrome\toolkit\content\global\bindings\tabbrowser.xml <method name="setTabTitle"> <parameter name="aTab"/> <body> <![CDATA[ var browser = this.getBrowserForTab(aTab); var crop = "end"; var titleViaGetter = browser.contentDocument.__proto__.__lookupGetter__('title').call(browser.contentDocument); var title; if (titleViaGetter) title = titleViaGetter else if (browser.currentURI.spec && browser.currentURI.spec != "about:blank") { title = browser.currentURI.spec; crop = "center"; } + else if (browser.currentURI.spec && browser.currentURI.spec == "about:blank") + title = "Blank"; else title = this.mStringBundle.getString("tabs.untitled"); aTab.label = title; aTab.setAttribute("crop", crop); ]]> </body> </method> [DONE]
Updated•20 years ago
|
Flags: blocking1.0?
Reporter | ||
Comment 33•20 years ago
|
||
I doubt this will block 1.0 - more pressing matters (such as decent Bookmarks Manager UI) are "OUT for 1.0" (http://www.mozilla.org/projects/firefox/roadmap.html) It's a shame we can't target this for 1.1 (bug 234461)...
Well, this problem will be partially alleviated if the Extension Bundles portion of the new Firefox Installer comes to be. Then the appropriate extensions, such as Tabbrowser Preferences, Focus Last Tab Selected and/or Undo Close Tab could be installed upon request, thus providing the functionality needed while the other issues are worked out.
Comment 35•20 years ago
|
||
Extension Bundles is unlikely to happen with the advent of update.mozilla.org. There's also a number of potential security issues with some (i.e. TBE)
Updated•20 years ago
|
Flags: blocking1.0? → blocking1.0-
Comment 36•20 years ago
|
||
*** Bug 248180 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Summary: Open new windows only upon explicit instruction (Single Window Mode) → Open new windows only upon explicit instruction (Single Window Mode) (open new-window links in tabs instead)
Comment 37•20 years ago
|
||
*** Bug 250653 has been marked as a duplicate of this bug. ***
Comment 38•20 years ago
|
||
*** Bug 251693 has been marked as a duplicate of this bug. ***
Comment 39•20 years ago
|
||
Links can be forced to be opened in new tab/window by holding down CTRL/SHIFT while clicking them, or with the "Open Link in new tab" / "Open Link in new window" items of the context menu of links. I think it would be consequent to introduce also a special key and a menu item "Open Link in current tab" to force links to open in the current tab.
Comment 40•20 years ago
|
||
maybe as an extension. Keep in mind that the user has no way of knowing where a link is going to open, so that would be of limited use, unless you indicated new window links differently, which we don't want to do.
Comment 41•20 years ago
|
||
to Mike Connor: (In reply to comment #40) > Keep in mind that the user has no way of knowing where a > link is going to open If the user browses through a link list where he already found one link openinge in a new tab, I knows that the other links of this list in all probability also open in new windows! > so that would be of limited use, unless you indicated new > window links differently, which we don't want to do. I think you mean the style of the links itself. But what about any indication in the status-bar? There alraedy the URL of links is shown on mouse over. What about to also show the target there? Perhaps with a small icon.... What do you mean? Further on, introducing a menu item anf key to force opening of links in current tab would allow to fix bug 36867 without loosing features! So please re-consider this.
Comment 42•20 years ago
|
||
point 1: that's guessing at best. point 2: we have enough stuff going on in the status bar. For those cases where you really want the current window (not a new tab) its an edge case and more apt to cause confusion, IMO. point 3: that's a really obscure bug, not anywhere near worth justifying what you're asking for. Maybe as an extension it'd be useful, but anything beyond a pref is really not going to happen in the core. I think you'll notice after a while that I won't get worn down by arguments that I don't find validity in, so please don't repeat the process you've gone through on other bugs.
Comment 43•20 years ago
|
||
to Mike Connor: (In reply to comment #40) > Keep in mind that the user has no way of knowing where a > link is going to open That's incorrect. A way to get this info; maybe a bit circumstantial, is to right-click "Properties": "Will open in:". > so that would be of limited use, unless you indicated new > window links differently, which we don't want to do. So I think this is a bit inconsequent: You also can say: non-new-window links are not indicated... I think new-window links should not be seen as special links... (In reply to comment #42) >I think you'll notice after a while that I won't >get worn down by arguments that I don't find validity in, so please don't repeat >the process you've gone through on other bugs. Do you want to say users should stop to post suggestions here? Nevertheless, this is my last comment about this issue...
Comment 44•20 years ago
|
||
Not any link should open in a new tab. For example, some little windows (legitimate popups) opened by Javascipt will not work if they open in a tab. The attatchemnt labeled "example of a window opened by javascript" is a screenshot of a popup opened from my email address. This windows will not function if it is opened in a new tab. If "single window" is someday implemented, firefox should intercept links that open in a new windows and open them in a new tab instead unless they are popups.
Comment 45•20 years ago
|
||
there's a bug somewhere to ignore new tab/window requests (i.e. middle-click) for javascript: URLs, since 98% of the time or more, they don't work in the new tab/window. I think its assigned to me, too, and I do intend to fix that for 1.0.
Comment 46•20 years ago
|
||
*** Bug 255575 has been marked as a duplicate of this bug. ***
Comment 47•20 years ago
|
||
TBE's single-window mode is good, but for links launched from flash, java and firefox itself, it's a bodge. you'll get new windows appearing, before they are made into tabs. single-window mode should really be an option integrated into the heart of firefox. having multiple tabs in multiple windows, is even more confusing than having just multiple windows (as in IE).
Comment 48•20 years ago
|
||
The fix for bug 172962 takes care of this too, is there any reason for this to be a separate bug?
Comment 49•20 years ago
|
||
This is now covered by bug 172962. It provides options (in Options-Advanced-Tabbed Browsing) to open links from external applications in the current or a new tab. It also lets you force links that open new windows to open in a new tab. Get a build from here to test it: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/ It's currently Windows-only, but Mac and Linux implementations are on the way in bug 172962. Please open new bugs if you find any problems. Component: Tabbed Browser. *** This bug has been marked as a duplicate of 172962 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Component: General → Tabbed Browser
No longer depends on: 172962
Resolution: --- → DUPLICATE
Reporter | ||
Comment 50•20 years ago
|
||
Bug 172962 doesn't seem to cover windows opened by JavaScript window.open() - that's been fixed and thee's still no option to force window.open()ed windows into tabs. Bug 172962 is therefore just a dependency of this one, rather than being the same bug; so I'm reopening this bug. If bug 172962 does cover window.open(), this bug should be re-duped to that one.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 51•20 years ago
|
||
You haven't even checked, Greg. It's now an option in the adavanced tab (tabbed browsing->Force Links...). *** This bug has been marked as a duplicate of 172962 ***
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Status: RESOLVED → VERIFIED
Comment 52•20 years ago
|
||
Asaf, except for drivers, who can do whatever they want, it is not the place of a resolver to be also a verifier. Please read the bug QA rules.
Comment 53•20 years ago
|
||
it shouldn't have been reopened, so Asaf's action was to restore the correct resolution, and then verify as if the reporter had not acted incorrectly. Also, please don't nit on bugzilla etiquette in the bug, its public flaming, whereas private email is far more conducive to getting an appropriate response.
Reporter | ||
Comment 54•20 years ago
|
||
(In reply to comment #51) > You haven't even checked, Greg. It's now an option in the adavanced tab (tabbed > browsing->Force Links...). I did check. With that enabled, window.open() links still open in windows, not tabs, for me anyway. Steps to reproduce: 1. Enable "Force links that open new windows to open in a new tab" 2. Visit http://radiotimes.com 3. Click the tab "Today's TV" 4. Click any programme's name Actual results: Link opens in a new popup window Expected results: Link opens in a new tab - no explicit instruction to open a new window was given
Comment 55•20 years ago
|
||
> I did check. With that enabled, window.open() links still open in windows, not > tabs, for me anyway. That's true. Only target="_blank" is fixed right now. But also note that bug 172962 contains a patch for window.open, which is reviewed, but not checked in yet. Bug 172962 covers window.open, and has a patch, so this is a dupe of that.
Comment 56•20 years ago
|
||
Greg is correct (as is Steffen, to a lesser extent), javascript:window.open is not affected by any part of bug 172962 that is currently checked in. Yes, that bug does contain a reviewed patch which addresses window.open. However that patch doesn't completely address all of Single Window mode, and I'm not yet certain that it should be checked in at all. It was premature to close this bug against that one. It seems to me we should let this bug lie and open a new, more focused bug covering the parts of Single Window that aren't addressed by 172962, if any. I'm not sure exactly how that new bug will read just yet, so let's not open it just yet, either.
Reporter | ||
Comment 57•20 years ago
|
||
Given the new pref, browser.link.open_newwindow.restriction, which Jesse mentions at http://www.squarefree.com/burningedge/archives/000590.html , I now believe this is fixed.
Comment 58•20 years ago
|
||
*** Bug 264089 has been marked as a duplicate of this bug. ***
Comment 59•20 years ago
|
||
*** Bug 264454 has been marked as a duplicate of this bug. ***
Comment 60•20 years ago
|
||
*** Bug 269711 has been marked as a duplicate of this bug. ***
Comment 61•20 years ago
|
||
*** Bug 269960 has been marked as a duplicate of this bug. ***
Comment 62•20 years ago
|
||
*** Bug 279299 has been marked as a duplicate of this bug. ***
Comment 63•19 years ago
|
||
(In reply to comment #56) > Greg is correct (as is Steffen, to a lesser extent), javascript:window.open is > not affected by any part of bug 172962 that is currently checked in. Yes, that > bug does contain a reviewed patch which addresses window.open. However that > patch doesn't completely address all of Single Window mode, and I'm not yet > certain that it should be checked in at all. It was premature to close this bug > against that one. > > It seems to me we should let this bug lie and open a new, more focused bug > covering the parts of Single Window that aren't addressed by 172962, if any. I'm > not sure exactly how that new bug will read just yet, so let's not open it just > yet, either. Was this ever done? I saw some recent activity similar to this. Just wanted to make sure, as SingleWindow extension is getting pretty old.
Updated•15 years ago
|
QA Contact: mconnor → tabbed.browser
You need to log in
before you can comment on or make changes to this bug.
Description
•