Closed Bug 143866 Opened 22 years ago Closed 18 years ago

Ctrl+T opens new tabs in tab-bar-less (popup, no toolbar) windows

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
seamonkey1.1alpha

People

(Reporter: luna.kil, Assigned: iannbugzilla)

References

()

Details

(4 keywords, Whiteboard: [asaP1])

Attachments

(2 files, 8 obsolete files)

4.36 KB, patch
iannbugzilla
: review+
jag+mozilla
: superreview+
benjamin
: approval1.8b4+
Details | Diff | Splinter Review
1.81 KB, patch
neil
: review+
Details | Diff | Splinter Review
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.
Assignee: mpt → jaggernaut
Status: UNCONFIRMED → NEW
Component: User Interface Design → Tabbed Browser
Ever confirmed: true
QA Contact: zach → sairuh
"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.
Keywords: dataloss, nsbeta1
nsbeta1- per Nav triage team.
Keywords: nsbeta1nsbeta1-
Target Milestone: --- → mozilla1.1beta
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. ***
QA Contact: sairuh → pmac
*** Bug 141521 has been marked as a duplicate of this bug. ***
*** Bug 152819 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
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. ***
Blocks: 182185
*** 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.
Severity: trivial → critical
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. ***
Summary: Ctrl+T opens new tabs in tab-bar-less windows → Ctrl+T opens new tabs in tab-bar-less (popup, no toolbar) windows
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.
Keywords: testcase
*** 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 ?
Attachment #149199 - Flags: superreview?(jag)
Attachment #149199 - Flags: review?(neil.parkwaycc.co.uk)
*** 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.
Attachment #149199 - Flags: review?(neil.parkwaycc.co.uk) → review-
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.
Flags: blocking-aviary1.0?
ben, can you have a look to see if there is anything that we can do here without
undue risk or regression.
Assignee: jag → bugs
would need a good patch to try and take this for 1.0 at this point.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
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
Attachment #149199 - Flags: superreview?(jag)
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.
Assignee: bugs → bugzilla
Attachment #149199 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #167072 - Flags: review?(neil.parkwaycc.co.uk)
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...
Attachment #167072 - Flags: review?(neil.parkwaycc.co.uk) → review-
A slightly tidier patch that also makes the use of const/var and capitalisation
more consistent.
Attachment #167072 - Attachment is obsolete: true
Attachment #167118 - Flags: review?(neil.parkwaycc.co.uk)
(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.
Attachment #167118 - Flags: review?(neil.parkwaycc.co.uk) → review+
(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.
Attached patch Tweak to navigator.js (obsolete) — Splinter Review
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.
Attachment #167118 - Flags: superreview?(jag)
Attachment #167271 - Flags: superreview?(jag)
Attachment #167271 - Flags: review?(neil.parkwaycc.co.uk)
(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...
Attachment #167271 - Flags: review?(neil.parkwaycc.co.uk) → review+
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. ***
Attachment #167118 - Flags: superreview?(jag)
Attachment #167271 - Flags: superreview?(jag)
Combined patch, carrying forward r+ and requesting sr.
Attachment #167118 - Attachment is obsolete: true
Attachment #167271 - Attachment is obsolete: true
Attachment #170162 - Flags: superreview?(jag)
Attachment #170162 - Flags: review+
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. ***
Attachment #170162 - Flags: superreview?(jag) → superreview?(alecf)
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.
Target Milestone: mozilla1.1beta → mozilla1.8beta
Attachment #170162 - Flags: superreview?(alecf) → superreview?(jag)
Flags: blocking-aviary1.1?
(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.)
Whiteboard: [asaP1]
Flags: blocking-aviary1.1? → blocking-aviary1.1+
belewfan, the blocking+ flags are for drivers.
Flags: blocking-aviary1.1+ → blocking-aviary1.1?
*** 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.
Attachment #170162 - Flags: superreview?(jag)
Attached patch Unbitrotted again patch v0.1d (obsolete) — Splinter Review
Changes since v0.1c:
* Unbitrotted the parts of tabbrowser.xml that had changed
Attachment #170162 - Attachment is obsolete: true
Attachment #188135 - Flags: review?(neil.parkwaycc.co.uk)
Flags: blocking1.8b4+
Attached patch Alternate patch v0.1e (obsolete) — Splinter Review
Changes since v0.1d:
* On toolbarless popup tabstrip always visible once additional tabs are opened
in popup even if they are closed again.
Attachment #188982 - Flags: review?(neil.parkwaycc.co.uk)
Flags: blocking-aviary1.1?
Attachment #188982 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #188135 - Flags: review?(neil.parkwaycc.co.uk)
Changes since v0.1e:
* window.toolbar.visible now has no affect on tab removal - so OS X widget does
not cause issues.
Attachment #188135 - Attachment is obsolete: true
Attachment #188982 - Attachment is obsolete: true
Attachment #188990 - Flags: review?(neil.parkwaycc.co.uk)
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?
Attachment #188990 - Attachment description: no toolbar.visible affect on remove patch v0.1f → no toolbar.visible effect on remove patch v0.1f
Attachment #188990 - Flags: review?(neil.parkwaycc.co.uk) → review+
Changes since v0.1f
* Removed autohide var completely as not really needed

Carrying forward r= and requesting sr=
Attachment #188990 - Attachment is obsolete: true
Attachment #188996 - Flags: superreview?(jag)
Attachment #188996 - Flags: review+
Flags: blocking1.8b4+
Comment on attachment 188996 [details] [diff] [review]
no autohide var patch v0.1g (Checked in)

Nice!
Attachment #188996 - Flags: superreview?(jag) → superreview+
Comment on attachment 188996 [details] [diff] [review]
no autohide var patch v0.1g (Checked in)

Requesting approval for fairly low risk patch
Attachment #188996 - Flags: approval1.8b4?
Attachment #188996 - Flags: approval1.8b4? → approval1.8b4+
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
Attachment #188996 - Attachment description: no autohide var patch v0.1g → no autohide var patch v0.1g (Checked in)
Firefox version of this patch is covered by bug 243893
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8
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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Regression window is between BuildIDs 2005120510 and 2005120611, likely candidate is checkin for Bug 105885
This patch:
* Removes chromeclass-toolbar class from tabbrowser-strip
Attachment #216869 - Flags: superreview?(neil)
Attachment #216869 - Flags: review?(neil)
Attachment #216869 - Flags: superreview?(neil)
Attachment #216869 - Flags: superreview+
Attachment #216869 - Flags: review?(neil)
Attachment #216869 - Flags: review+
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
Attachment #216869 - Attachment description: Regression fix due to bug 105885 checkin v0.2 → Regression fix due to bug 105885 checkin v0.2 (Checked in trunk)
Component: Tabbed Browser → XP Apps
Product: Core → Mozilla Application Suite
Target Milestone: mozilla1.8beta1 → seamonkey1.1alpha
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
Attachment #216869 - Flags: approval-seamonkey1.1a?
Attachment #216869 - Flags: approval-seamonkey1.0.1?
Flags: blocking-seamonkey1.1a?
Flags: blocking-seamonkey1.0.1?
Attachment #216869 - Flags: approval-seamonkey1.1a? → approval-seamonkey1.1a+
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
Attachment #216869 - Attachment description: Regression fix due to bug 105885 checkin v0.2 (Checked in trunk) → Regression fix due to bug 105885 checkin v0.2 (Checked in trunk & 1.8 branch)
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
Attachment #216869 - Flags: approval-seamonkey1.0.2+
Attachment #216869 - Flags: approval-seamonkey1.0.1?
Attachment #216869 - Flags: approval-seamonkey1.0.1-
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 ;-)
Flags: blocking-seamonkey1.1a?
Flags: blocking-seamonkey1.1a-
Flags: blocking-seamonkey1.0.1?
Flags: blocking-seamonkey1.0.1-
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
Attachment #216869 - Attachment description: Regression fix due to bug 105885 checkin v0.2 (Checked in trunk & 1.8 branch) → Regression fix due to bug 105885 checkin v0.2 (Checked in trunk & 1.8 & 1.8.0 branch)
Status: REOPENED → RESOLVED
Closed: 19 years ago18 years ago
Resolution: --- → FIXED
Whiteboard: [asaP1] → [asaP1] fixed-seamonkey1.0.2
Whiteboard: [asaP1] fixed-seamonkey1.0.2 → [asaP1]
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" ;-) 
Keywords: verified1.8.0.4
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.  
Keywords: verified1.8.0.4
(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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: