If you accidently press CTRL+T in a window that doesn't have a tab bar (a popup-window for example), Mozilla will open a new tab. This leaves the user with a blank page inside the window and no way to return to the previous page (the other tab). Mozilla should open a new page in another window instead. Pressing CTRL+T instead of CTRL+N has become a habit of many.

I can confirm that a new tab gets opened without displaying the tab bar. There is still the posibility to change Tabs with CTRL-PgUP / CTRL-PgDn. But I don't think this is a good way to handle this case. In my opinion you're right. No Tabs should be opened in windows that got created through JavaScript. Perhaps the new tab could be put in the Parent window. I searched for a dup of this bug and didn't find any. If I were right, it would be nice if someone could change this to new. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510

ctrl-shift-l works, i'd imagine ctrl-w works, personally i don't want sites to get smart and decide that if they create a new window of fixed size they can prevent me from using tabbed browsing (if i'm crazy enough to use it). it does appear that we don't provide a tab strip. i'm not sure i want to call that a bug or a feature. if you have dom inspector installed (i don't) you can make the bar visible by removing some attribute. all i'm doing is confirming the summary.

"i don't want sites to get smart and decide that if they create a new window of fixed size they can prevent me from using tabbed browsing (if i'm crazy enough to use it)." So the problem is, that we don't get the tab bar. Maybe it is possible to display the bar if someone presses CTRL-T. And if the window has a fixed size, it is resized in height so that the client area keeps its dimensions.

note that the os may not allow us to change the dimensions of a fixed sized window, after all we promised the os it was a fixed size. fwiw if you're familiar with javascript programming then you can probably solve the tabbar visibility issues. visit #mozillazine on irc.mozilla.org and say you'd like to know how to hack tabbrowser.

Well, at least I was familiar with JavaScript programming. I didn't do it for quite some time, but if its not so hard, I could try. But what should be the result? That the tabbar gets visible if there is more than one tab and the client area shrinks?

I just had this happen to me while filling out a form. Users loose all the data they typed into the form when this happens since it's not clear how to get back to the other hidden tabs. This is easily reproducible by using the context menu on a link.

nsbeta1- per Nav triage team.

Hi There This just happened to me so I found this bug. I'm using a webmail which opens mails in a new (JS-)Window with no url- and other bars. Then I pressed the middle mouse button over a link so this opened in a new tab.. i was still able to use them with mouse gestures, but in my (consumer-)opinion i would much prefer that the tab bar gets visible than anything different to this... Opening in the parent window.. dangerous, what if that doesn't exist anymore? And how should the user find that new tab especially when he (like me) has activated that tabs should open in background and not take focus? If adding the bar to a js-window is a OS Problem (fixed size and stuff) I think it would be best to open a new window... Just my cents to this cause I would like to see this fixed :)) Thanks for listening, you were a great audience. Matti

Comment 3 sez: > So the problem is, that we don't get the tab bar. Agreed. Opening a new tab, by any means, should always make the tab bar visible, if it isn't already. > note that the os may not allow us to change the > dimensions of a fixed sized window, after all we > promised the os it was a fixed size. Err, why exactly did we promise that? Is there *any* situation (apart from chrome) where we don't want the user to be able to resize the window if desired? (Answer: only if we are control freaks and don't want the user to have any say-so. Unresizeable windows are an inexcusable evil.)

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

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

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

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

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

being able to re-enable the tool bars and tab bars from a right click context menu would be a good solution to these problems regards JG

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

From Bug 168403 (which should be marked as a dup of this): > 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 Seems to me that if the tab-bar is considered part of one of these other bars for javascript purposes, then providing a tab-bar in a window that javascript explicitly opened without these bars would be breaking javascript. On the other hand, if we consider the tab-bar a separate ui component, then we should display it, and we must be prepared to show a tab-bar at all times for those who have "Hide the tab bar when only one tab is open" preference unselected. By initially hiding the tab-bar irrespective of preference and then popping one up when needed, we get the worst of both worlds: we break preferences, AND we break javascript by allowing users the undocumented ability to over-ride the javascript "open" arguments. My preference would be the following: accept that the intention of the javascript "open" was to create a window with minimum chrome. Therefore, the tab-bar should not be displayable in this window. Tabbed browsing is therefore disabled for that window. So ctrl-T should not work, the "open in new tab" in the context menu should be greyed out, etc. And to the argument that we don't want sites preventing us from using tabbed browsing, I say that sites are already preventing us from using bookmarks, printing, going home, and countless other chrome-dependent things for these kinds of windows, so loss of tabbed browsing for these windows is no great loss.

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

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

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

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

A few comments... 1) the keyboard shortcuts for switching tabs don't allways work if you create a new blank tab (i believe this is because of bug#172556) 2) I'm all in favor of "being able to re-enable the tool bars and tab bars from a right click context menu" but that seems like a seperate issue, specificly "Should a context menu have options for enabling window elements that the window opener orriginal eliminated?" 3) If a window contains more then one tab, then there needs to be a tab-bar in that window -- that seems like a no brainer to me. 4) I don't think the Tab-Bar should be tied directly to any of the other toolbars ... it should be possible to have one without the others. 5) i personally think that it should allways be possible to create a new tab, and the tab-bar should allways obey the users "hide tab-bar if only one tab" preference in all windows (even in fixed sized 'popups' if they have the option set to 'false') ... if that's not viable for some technical reason, then i think that it should be impossible to create a new tab in any window that can't/won't display the tab-bar. I would go so far as to suggest that atempting to do so should generate an error/warning dialog box.

I think a better solution would be to follow the following philosophy. New features (such as tabs) require new API's because they are new and do new things! > 3) If a window contains more then one tab, then there needs to be a tab-bar in that window -- that seems like a no brainer to me. > 4) I don't think the Tab-Bar should be tied directly to any of the other toolbars ... it should be possible to have one without the others. I totally agree with these two statements. The tab is a NEW feature and a NEW UI component. The javascript open command should be changed to add support for that new component. Until it does change, the js open command should IGNORE the tab bar. If there are multiple tabs, the tab bar shows up. If there is 1 tab the preference decides whether or not the bar shows up. | "accept that the intention of the javascript "open" was to create a | window with minimum chrome. " The point of the open command is to OPEN a window--NOT open a window with minimum chrom. Perhaps it was meant as | "accept that the intention of the javascript "open" > [with toolbar=no, menubar=no, and statusbar=no] | was to create a window with minimum chrome This statement is more defendable but it is a special case of specific UI components=no. Perhaps backwards compatibility requires that when all these are specified as OFF then we assume that the tab bar is not there either BUT that brings up all these other questions. Furthermore what if I want the tab bar but not the menu, status, or toolbar? We are deciding here if that should even be possible and I think it should. I still maintain that the js open command should be amended to know about tabs and ignore it until then. How many browsers have tabs now? Many do. It is probably time to add tabs to the WWW standards and treat them as a new feature--not treat them as a hack that sometimes works.

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

Unresizeable windows are bug 101509 and bug 107949; IMO we don't need to concern ourselves with that problem here. This is simple: if there are multiple tabs, there should be a tab bar. If there is only one tab in the window, then it's up to the user's pref, which has been in the prefs dialog for some time now and should be followed. If adding the tab bar causes content to not fit, the user can scroll or resize as desired (and if not, that is a separate bug). We could theoretically get into the arcane nuances of adding a second pref to allow scripts to override the first one, if we find users who actually want websites to be able to tell them what chrome features to have or not have; in that case, the pref dialog could be reworded: Show the tab bar: ( ) Always ( ) Always, unless a script turns it off (*) Only when there is more than one tab open I'm really not sure that's necessary, though; I have difficulty imagining that users would select the second option. Some websites might _want_ them to select that option, but they don't get to decide.

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

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

In bug 107949 a pref was added, dom.disable_window_open_feature.toolbar, which can be set to 'true' to always force a tab bar to appear on popups. This is only adequate if a user knows to turn it on to solve the problem of this bug. Currently the pref is not in a UI other than about:config, about which the beginnner will be unknowledgeable. The beginner will also unlikely be familiar with using CTRL-Tab to cycle between tabs in the popup, since the whole issue of short cut keys is not engagingly documented. The drawback of the current (1.4 rc1) implementation of this pref is that, thereafter, a tab bar is shown on every popup even if the user will not have need of the tab bar in that popup. 1)A compromise might be to show the tab bar if and only if the user requests (or site designer forces) a second tab in the pop up and the pref is set to false (most straightforward user experience) 2)Another possibility is a timed nag window which says something like 'Use CTRL-tab to see other tabs in this popup" as the new tab in the popup is being made. (requires user to learn a new behavior if he never heard of CTRL-tab and remember the behaiovior) 3)Another possibility is adding a status bar to the popup which has the message of #2 when a tab gets added to the popup (requires user to learn a new place to get hints) 4)Another possibility is add a different menu item on right clicks within the popup "open in new tab in this popup" (follows current user experience but not adequate if site designer forced the new tab from a link) 5) Another possibility is open up a new tab in parent window (hard for user to know the meaning of Back button in that context) But all this is getting too convoluted. Ideally, shouldn't the behavior simply follow the normal window behavior? i.e if the pref is on the tab bar is always there. if the pref is off (current default), a tab bar appears in the popup and the new tab contains the user requested/site-designer-forced stuff. In any case, if the pref above is false, the tab should open up somewhere visible!

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

Changed the subject to make it a little easier to find (there were several dups, and I almost filed a dup myself because the phrase "tab-bar-less" didn't occur to me.) If you don't like it, feel free to change it back. :-)

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

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

possible dupes: bug 151157 bug 225971 (first comment in that report contains other bugs it may be duped to)

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

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

The last duped bug had a testcase at http://www.hut.fi/u/tsknorri/mozilla/popup_tab.html The popup window in this testcase is being opened with window.open('popup_tab_red.html','popup','width=500,height=500,toolbar=no,location=no'); so switching off toolbar and location bar is enough to prevent the tab bar from appearing.

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

That menu item and ctrl+t should be disabled, if the toolbar is hidden. See also: http://bugzilla.mozilla.org/show_bug.cgi?id=112921 Or was this another design error?

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

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

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

See also bug 234298, same bug for Firefox.

(In reply to comment #40) > *** Bug 234308 has been marked as a duplicate of this bug. *** Actually it seems that the bug is the fact, that the tabbar is regarded as a part of toolbar. dom.disable_window_open_feature.toolbar works, but shows toolbar also, which is also not optimal. In my opinion ideal solution would be to have the toolbar and tabbar independent and not treat toolbar=no valid for tabbar (all in all, all you can use tabbar for is tab switching, so no security consequences .. )

Confirming on Mac. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031026 Firebird/0.7 (Not using Firefox b/c it's too unstable.)

(In reply to comment #43) > In my opinion ideal > solution would be to have the toolbar and tabbar independent and not > treat toolbar=no valid for tabbar Yes, for toolbars in the xul.css is a rule: window[chromehidden~="location"][chromehidden~="toolbar"] .chromeclass-toolbar {display:none} Problem is that in the tabbrowser.xml is: <xul:hbox class="tabbrowser-strip chromeclass-toolbar" and so tabbar of tabrowser is hidden too. I agree, that the tabbar != toolbar, so should be visible in the toolbar=no windows too. Patch is comming...

Comment on attachment 149199 [details] [diff] [review] Path - don't hide tabbrowser with toolbar=no Some tip for the sr ?

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

Comment on attachment 149199 [details] [diff] [review] Path - don't hide tabbrowser with toolbar=no As this stands this will regress bug 112921. What might be acceptable is to disable the hiding mechanism when a new tab is opened.

Today I watched my relatively-clueful roommate lose a large, nearly-finished webmail by accidentally CTRL-clicking instead of SHIFT-clicking a link in the Compose popup. "Back" was disabled in the context menu, and there was no indication that he had opened a new tab (and no UI to close the tab). He closed the window and lost the email before I could explain what was going on. I'm requesting blocking-aviary1.0 because of the potential for millions of people to do the same thing. Also, I believe that bug 112921 was the wrong fix and should be backed out. The correct behavior is to autohide (not always hide, see browser.tabs.autoHide) the tabbbar for windows without chrome.

ben, can you have a look to see if there is anything that we can do here without undue risk or regression.

would need a good patch to try and take this for 1.0 at this point.

Is this going to be fixed for 1.0? It should be fairly easy to fix (and i'm sure 1.0 PR didn't have this problem).

First, this bug is targeted against *Mozilla* not Firefox. (Comment 52 may have mislead you - although it's certainly possible that whatever Seamonkey fix is put in place can be ported over to and/or include Firefox.) Secondly, the problem has existed for at two and a half years now - since the bug was filed at that time - before Firefox was even conceived of as Phoenix (if I recall correctly), so it's always been a problem...

My two cents: This is unnacceptable behaviour, might lead to data loss and is very confusing. Should have been fixed in FF1.0 (I known, wrong place...) and any future releases of the Browser. The user should always have control - windows shouldn't be forcibly fixed size (suppose the user switches resolution?) Also, all restrictions imposed via javascript open() are merely cosmetic: user usualy is able to do what he wants, through keyboard shortcuts or using javascript or using dom inspector or whatever. If the user hits F11 to go fullscreen, is that a popup window or just another window, where he might continue browsing as normal? (by the way, hitting F11 again doesn't bring him back to the same sized popup window... but a maximized window... another bug.) Developers should never assume they control the user environment. So, there are two approaches: handle popup chromeless windows as 'special' windows, wich never open new tabs or external links; or handle those popup windows as something that the user can revert to a normal window, that is, restore the full menus and tab bar.

I do agree with Gaspar, this bug is annoying. One solution could be that when on popup window with toolbars is created it stays that way (no toolsbars), but when an user opens an tab in that window, a tab-bar from the chrome would become (automatically) visible. Does the user really need for a manual way to change chromeless windows to chromed ones?

This bug has been open over 2 years. This is unacceptable for the users who encounter the problem if you ask me. Can we summarise the problem, come up with an effective solution and solve it rather than bickering over functionalit. Mozilla seems to like pushing paper rather than solving problems...

This is an open source community. If you want to see this bug fixed, then submit a patch yourself. Complaining about the lack of progress is a sure way of upsetting the volunteers who spend their free time on this, and a good way of ensuring that nothing will get done. Please familiarize yourself with the Bugzilla Etiquette guidelines: http://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment on attachment 149199 [details] [diff] [review] Path - don't hide tabbrowser with toolbar=no Cancelling old sr request

This patch tweaks the behaviour of tabbrowser.xml so that when a new tab is opened in a window with toolbar=no then a tabbrowser toolbar is shown.

Comment on attachment 167072 [details] [diff] [review] Patch v0.1 - only show tabbrowser when more than one tab open with toolbar=no >-window[chromehidden~="location"][chromehidden~="toolbar"] .chromeclass-toolbar >+window[chromehidden~="location"][chromehidden~="toolbar"] .chromeclass-toolbar:not([class~="tabbrowser-strip"]) Since you're manually updating the tabstrip, why not remove the chromeclass from the element? It was only added to fix bug 112921. >+ var chromehide = (this.ownerDocument.documentElement >+ .getAttribute("chromehidden").indexOf("toolbar") != -1); Compare this to the last hunk of the patch. I see one big difference and one subtle difference...

A slightly tidier patch that also makes the use of const/var and capitalisation more consistent.

(In reply to comment #60) > Created an attachment (id=167072) > Patch v0.1 - only show tabbrowser when more than one tab open with toolbar=no > > This patch tweaks the behaviour of tabbrowser.xml so that when a new tab is > opened in a window with toolbar=no then a tabbrowser toolbar is shown. What if a popup window disables one or more of the following window features: "titlebar", "menubar", "toolbar", "location", "personalbar", "directories", "minimizable", "resizable", "close", "scrollbars", "status" set height=250 and disable scrollbars, what now?

Comment on attachment 167118 [details] [diff] [review] Patch v0.1a - tidier patch to show tabstrip only when more than one tab is open with toolbar=no I just noticed one flaw when testing this; there's a preference listener in navigator.js of all places that needs to be tweaked in case the toolbar is hidden.

(In reply to comment #64) > (From update of attachment 167118 [details] [diff] [review]) > I just noticed one flaw when testing this; there's a preference listener in > navigator.js of all places that needs to be tweaked in case the toolbar is > hidden. Neil, why have a tabbar, if you can't resize that window, or can't scroll? Am I missing something?

HJ - this bug is about toolbar=no, if you feel setting those other options to =no is a problem, log a bug report about it/them.

Tweak to navigator.js so it does not produce a tabstrip for toolbar=no windows with only one tab even if preference (autoHide to off) is changed when window is open.

(In reply to comment #66) > HJ - this bug is about toolbar=no, if you feel setting those other options to > =no is a problem, log a bug report about it/them. Again, what is the point of having a tab bar, of you can't scroll or resize that window, and that are just two examples, but I guess that you don't want to write a patch that works...100% that is. p.s. I wrote a patch for MultiZilla two years ago, so I know what is going to happen ;)

> Again, what is the point of having a tab bar, of you can't scroll or resize > that window To actually be able to switch between the tabs? The whole point of this bug is that currently you can get a tabbar-less window as a popup and you hit <Ctrl> T. Then you end up opening another tab - without any kind of tabbar to control it. Having something be resizable / scrollable would be a different bug, not this one. This one is only about getting the basic tabbar functionality in place. Improvements / changes to this can be handled later...

Go ahead and flame me if I'm bringing up a solution that's been discussed and discarded, but what about disallowing multiple tabs in "minimal popup" windows (toolbar=no and ...)? Remove any UI that allows creation of a second tab, redirect keyboard shortcuts that would open a new tab to a new window (or perhaps a new tab in another window and bring that to the front?). Of course, it'd be a lot of work and it's all just to protect the user against this situation where the window is small and can't be resized. Viewed in that light, I'm guessing the user, after opening the additional tab, would either grin and bear it, or shake his head, close it, and open it in (another tab in) another window. So I'd say, this patch looks promising, and doesn't necessarily have to deal with the small window case. I'll try and get around to actually code reviewing it later this week.

(In reply to comment #70) > Go ahead and flame me if I'm bringing up a solution that's been discussed and > discarded, but what about disallowing multiple tabs in "minimal popup" windows > (toolbar=no and ...)? Remove any UI that allows creation of a second tab, > redirect keyboard shortcuts that would open a new tab to a new window (or > perhaps a new tab in another window and bring that to the front?). IMHO redirecting new tabs to the previous chromed window would be the best option; that way tabbed browsing can still be used without opening it in the chromeless popup.

IMHO nobody really needs tabbeld popup-windows... Best would be to disallow tabs is such cases. The intention of this bugreport (I also wrote a dupe... ;-)) was, not to loose the content of a window because you do not see it anymore. And this may happen due to a window if it pops up and you are not aware that it now has the focus. If some presses CTRL+T on a popup, just do not do it. If someone wants to open a link from the window in a tab, use the parent of it, where tabs are allowed. Robert

(In reply to comment #72) > IMHO nobody really needs tabbeld popup-windows... Best would be to disallow > tabs is such cases. oh come on. what a silly idea. tabs in popups are pretty useful. for example i use a webchat that displays a message in popup and tabs are great for lookin in the archive etc (where same geometry is useful, but also tabs are logically grouped together) using originating windows is not a good idea .. it already has lot of tabs ..

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

Combined patch, carrying forward r+ and requesting sr.

As per bug 231342 Mac users can actually toggle the toolbar on or off, which complicates matters, as this code only performs a static check.

(In reply to comment #76) > As per bug 231342 Mac users can actually toggle the toolbar on or off, which > complicates matters, as this code only performs a static check. The mac collapse toolbar button is not expected to hide the tabbar, this should probably get fixed by this patch (which removes "chromeclass-toolbar" from the tabbar, it should be enough for nsWebShellWindow::Toolbar).

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

See also bug 267655, which I don't think is a direct dupe of this but which illustrates another undesireable result of allowing tabs in crippled windows.

(Since others have mentioned it, turning chrome back on is bug 26353. But that would not, by any stretch of the imagination, be a proper fix for this bug.)

belewfan, the blocking+ flags are for drivers.

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

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

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

(In reply to comment #77) >(In reply to comment #76) >> As per bug 231342 Mac users can actually toggle the toolbar on or off, which >> complicates matters, as this code only performs a static check. >The mac collapse toolbar button is not expected to hide the tabbar, this should >probably get fixed by this patch (which removes "chromeclass-toolbar" from the >tabbar, it should be enough for nsWebShellWindow::Toolbar). That's not the point. The code looks at window.toolbar.visible at the time it decides whether it needs to hide the tab bar. This means if you take an ordinary window, hit the mac collapse toolbar button and close other tabs it will always hide the tab bar, just as if the window was opened without toolbars.

Changes since v0.1c: * Unbitrotted the parts of tabbrowser.xml that had changed

Changes since v0.1d: * On toolbarless popup tabstrip always visible once additional tabs are opened in popup even if they are closed again.

Changes since v0.1e: * window.toolbar.visible now has no affect on tab removal - so OS X widget does not cause issues.

Comment on attachment 188990 [details] [diff] [review] no toolbar.visible effect on remove patch v0.1f >- var autohide = this.mPrefs.getBoolPref("browser.tabs.autoHide"); >- if (autohide) >+ var autoHide = this.mPrefs.getBoolPref("browser.tabs.autoHide"); >+ if (autoHide) Is anything actually changing here?

Changes since v0.1f * Removed autohide var completely as not really needed Carrying forward r= and requesting sr=

Comment on attachment 188996 [details] [diff] [review] no autohide var patch v0.1g (Checked in) Nice!

Comment on attachment 188996 [details] [diff] [review] no autohide var patch v0.1g (Checked in) Requesting approval for fairly low risk patch

Comment on attachment 188996 [details] [diff] [review] no autohide var patch v0.1g (Checked in) Checking in global/resources/content/bindings/tabbrowser.xml; new revision: 1.122; previous revision: 1.121 browser/resources/content/navigator.js; new revision: 1.574; previous revision: 1.573 done

Firefox version of this patch is covered by bug 243893

Verified FIXED using build 2005-08-08-05 of SeaMonkey trunk on Windows XP; Firefox is covered by bug 243893, so a separate verification can and should be done there.

I just tested this in seamonkey nightly builds from 2006/3/28. This was supposed to have been fixed in August of last year? It is NOT FIXED based on my experience AND a test case mentioned IN THIS BUG. http://www.hut.fi/u/tsknorri/mozilla/popup_tab.html The firefox fix forces the tab bar to be visible in this situation (IMHO this is the best solution). Did the patch get lost on it's way into the seamonkey tree? Did I try the wrong builds? Moz 1.7.2 also has this problem.

You are correct, this has regressed -> reopening

Regression window is between BuildIDs 2005120510 and 2005120611, likely candidate is checkin for Bug 105885

This patch: * Removes chromeclass-toolbar class from tabbrowser-strip

Comment on attachment 216869 [details] [diff] [review] Regression fix due to bug 105885 checkin v0.2 (Checked in trunk & 1.8 & 1.8.0 branch) Checking in (trunk) tabbrowser.xml; new revision: 1.150; previous revision: 1.149 done

Comment on attachment 216869 [details] [diff] [review] Regression fix due to bug 105885 checkin v0.2 (Checked in trunk & 1.8 & 1.8.0 branch) We really need this regression fix in both SM1.0.x and SM1.1

Comment on attachment 216869 [details] [diff] [review] Regression fix due to bug 105885 checkin v0.2 (Checked in trunk & 1.8 & 1.8.0 branch) a=me for 1.1, but we need to push this off to 1.0.2 as 1.0.1 is frozen already.

Comment on attachment 216869 [details] [diff] [review] Regression fix due to bug 105885 checkin v0.2 (Checked in trunk & 1.8 & 1.8.0 branch) Checking in (1.8 branch) tabbrowser.xml; new revision: 1.126.2.17; previous revision: 1.126.2.16 done

Comment on attachment 216869 [details] [diff] [review] Regression fix due to bug 105885 checkin v0.2 (Checked in trunk & 1.8 & 1.8.0 branch) 1.0.1 is done already on the source side, but looks good to me for 1.0.2

1.0.1 is already done, and on 1.8 branch it's checked in, so no need to decide on blocker status any more ;-)

The firefox bug 234298 has been duped againt this bug....Nasty. bug 243893 even though tabs still open in maimed popup windows instead of the main browser window (which I believe is the purpose of these bugs). Robin

Comment on attachment 216869 [details] [diff] [review] Regression fix due to bug 105885 checkin v0.2 (Checked in trunk & 1.8 & 1.8.0 branch) Checking in (1.8.0 branch) tabbrowser.xml; new revision: 1.126.2.4.2.10; previous revision: 1.126.2.4.2.9 done

verified on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060504 Firefox/1.5.0.4

(In reply to comment #108) > verified on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) > Gecko/20060504 Firefox/1.5.0.4 > Tracy, the "Product" is "Mozilla Application Suite" ;-)

The fix for the this product was also checked into the 1.8.0 branch. Please don't remove keywords for branches a fix has been checked into. Putting the keyword back.

(In reply to comment #110) > The fix for the this product was also checked into the 1.8.0 branch. Please > don't remove keywords for branches a fix has been checked into. Putting the > keyword back. It's quite hard to verify this on a Firefox build since "verified1.8.0.4" assumes that the particular fix has been tested in a seamonkey 1.8.0.4 branch build...

fixed1.8.0.4 is used, in all products, to indicate that the fix is committed against the branch that will produce _Gecko_ 1.8.0.4, not necessarily a SeaMonkey release from that branch or any other. (See the "fixed-seamonkey" flags for those.) verified1.8.0.4 similarly. If you think a keyword was misapplied, please feel free to comment to that effect, but please _don't_ remove them; it makes for a lot of pain in our release status tracking. Thanks!

gavin just pointed me to the firefox version of this bug. bug 243893. I'll reset to fixed1.8.0.4

Ah, so the Firefox specific keywords actually do not belong here because there is a dedicated bug for Fx.