User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2a) Gecko/20020910 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2a) Gecko/20020910 Some pages use the javascript "open" function to open new pages. This function can be used with "location=no, toolbar=no, menubar=no, statusbar=no" arguments to produce a window without any browser widgets -- the window is just a container for Web content. If you right click a link in one of these pages, you can still select "Open link in new tab". The result is that the browser thinks it is opening the link in a new tab. It gives you the link in the current page, and it even starts with a fresh history, so you can't go back. But of course there is no tab bar so there are no tabs. This is a pain, because the only reason we open things in new tabs is because we want to retain access to the original page. As things currently stand, opening in a new tab is actually worse than just clicking on the link, because the current page is overwritten *and* the history is lost. Reproducible: Always Steps to Reproduce: 1. Go to http://www.pss.gov.au/pss/tools/calculate.html 2. Click on "Member Services Online". A new window opens with no location bar, no toolbar, no menubar and no statusbar. 3. Right click on any link in this new page, and select "Open link in new tab". 4. The new page appears, but not in a new tab, because there is no tab bar for the new tab to hang off. 5. Right click anywhere on this new page. The "back" menu item is greyed out -- you can't get back to the original page. Expected Results: I suppose there are two reasonable options: EITHER 1. Presumably the tab bar is associated with either the toolbar or the menubar or the location bar for javascript "open()" purposes. Perhaps it should be disassociated from these other bars so that it still appears even when these others do not. OR 2. When a window is opened without a toolbar (or menubar or location bar or whatever it is that tabs are attached to for javascript "open" purposes), then the "open link in new tab" menu item should be greyed out.

How about: 3) For such windows, when the user opens the second tab, show all the relevant UI (navigation bar, tab bar, status bar, ...?) ?

I don't think that would work. If the new tab contained a tab bar, then the user would be able to use it to switch back to the original tab, which doesn't have a tab bar. Then there would be no way to switch to the new tab. Let's face it: tabbed browsing doesn't work unless EVERY tab comes with a tab bar. But I can think of another option: 4) When a user chooses "Open in new tab" in a window without a tab bar, overrule the original window preferences and create a tab bar for that window. Then proceed as usual. This would be completely transparent for people who have "Hide the tab bar when only one tab is open" selected in their preferences; and it wouldn't be too ugly for other users.

> I don't think that would work. If the new tab contained a tab bar, then the user > would be able to use it to switch back to the original tab, which doesn't have a > tab bar. Then there would be no way to switch to the new tab. Let's face it: > tabbed browsing doesn't work unless EVERY tab comes with a tab bar. I think you missed something here. The tab bar is not part of a tab, so once it's shown for the second tab, if the user switches back to the first tab the tab bar will still be there (until explicitely hidden). Put differently, your #4 is what I meant :-)

Yes, I see what you mean. I guess showing the tab bar alone would be an acceptable solution, since the javascript "open" function can't specify whether or not the tab bar should be present. But I think it would be a bad thing if "Open in new tab" had the side-effect of | show all the relevant | UI (navigation bar, tab bar, status bar, ...?) for the original window which was specifically opened with "location=no, toolbar=no, menubar=no, statusbar=no" arguments.

:-(, i like windows with tabs and no chrome, you can hide things from your neighbors or PHB and there's no evidence.

*** Bug 176133 has been marked as a duplicate of this bug. ***

dup of bug 143866?

*** This bug has been marked as a duplicate of 143866 ***