Last Comment Bug 143866 - Ctrl+T opens new tabs in tab-bar-less (popup, no toolbar) windows
: Ctrl+T opens new tabs in tab-bar-less (popup, no toolbar) windows
Status: VERIFIED FIXED
[asaP1]
: dataloss, fixed-seamonkey1.0.2, fixed-seamonkey1.1a, testcase
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: All All
: -- critical with 14 votes (vote)
: seamonkey1.1alpha
Assigned To: Ian Neal
: Patty Mac
Mentors:
http://www.hut.fi/u/tsknorri/mozilla/...
: 141521 143468 151157 152819 157146 168403 169031 185993 188676 189159 193836 207777 211414 219777 225971 232039 232426 234298 234308 234342 279460 293857 296543 (view as bug list)
Depends on:
Blocks: 182185 243893
  Show dependency treegraph
 
Reported: 2002-05-12 03:56 PDT by Henning Koch
Modified: 2009-10-14 06:38 PDT (History)
61 users (show)
chofmann: blocking‑aviary1.0-
kairo: blocking‑seamonkey1.0.1-
kairo: blocking‑seamonkey1.1a-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Path - don't hide tabbrowser with toolbar=no (1.11 KB, patch)
2004-05-24 05:23 PDT, Met - Martin Hassman
neil: review-
Details | Diff | Review
Patch v0.1 - only show tabbrowser when more than one tab open with toolbar=no (3.11 KB, patch)
2004-11-25 18:07 PST, Ian Neal
neil: review-
Details | Diff | Review
Patch v0.1a - tidier patch to show tabstrip only when more than one tab is open with toolbar=no (3.61 KB, patch)
2004-11-26 07:26 PST, Ian Neal
neil: review+
Details | Diff | Review
Tweak to navigator.js (1005 bytes, patch)
2004-11-28 10:54 PST, Ian Neal
neil: review+
Details | Diff | Review
Unbitrotted combined tabstrip fix for tabbrowser.xml and navigator.js v0.1c (4.77 KB, patch)
2005-01-03 09:49 PST, Ian Neal
iann_bugzilla: review+
Details | Diff | Review
Unbitrotted again patch v0.1d (4.47 KB, patch)
2005-07-03 14:30 PDT, Ian Neal
no flags Details | Diff | Review
Alternate patch v0.1e (4.47 KB, patch)
2005-07-11 15:16 PDT, Ian Neal
no flags Details | Diff | Review
no toolbar.visible effect on remove patch v0.1f (4.40 KB, patch)
2005-07-11 16:30 PDT, Ian Neal
neil: review+
Details | Diff | Review
no autohide var patch v0.1g (Checked in) (4.36 KB, patch)
2005-07-11 17:21 PDT, Ian Neal
iann_bugzilla: review+
jag-mozilla: superreview+
benjamin: approval1.8b4+
Details | Diff | Review
Regression fix due to bug 105885 checkin v0.2 (Checked in trunk & 1.8 & 1.8.0 branch) (1.81 KB, patch)
2006-03-31 13:56 PST, Ian Neal
neil: review+
neil: superreview+
kairo: approval‑seamonkey1.0.1-
kairo: approval‑seamonkey1.0.2+
csthomas: approval‑seamonkey1.1a+
Details | Diff | Review

Description Henning Koch 2002-05-12 03:56:40 PDT
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.
Comment 1 Stefan Bach 2002-05-12 13:07:12 PDT
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
Comment 2 timeless 2002-05-12 13:40:08 PDT
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.
Comment 3 Stefan Bach 2002-05-13 00:49:19 PDT
"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.
Comment 4 timeless 2002-05-13 04:52:59 PDT
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.
Comment 5 Stefan Bach 2002-05-13 05:26:55 PDT
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?
Comment 6 Joseph Elwell 2002-05-20 17:47:21 PDT
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.
Comment 7 Peter Trudelle 2002-05-21 14:53:40 PDT
nsbeta1- per Nav triage team.
Comment 8 Matti 2002-06-11 07:16:16 PDT
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 9 Jonadab the Unsightly One (Nathan Eady) 2002-06-29 09:17:40 PDT
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.)

Comment 10 Alfonso Martinez 2002-07-07 09:59:59 PDT
*** Bug 143468 has been marked as a duplicate of this bug. ***
Comment 11 Alfonso Martinez 2002-07-12 10:14:23 PDT
*** Bug 157146 has been marked as a duplicate of this bug. ***
Comment 12 Jason Bassford 2002-09-16 15:46:35 PDT
*** Bug 169031 has been marked as a duplicate of this bug. ***
Comment 13 Hasse 2002-11-26 07:45:55 PST
*** Bug 141521 has been marked as a duplicate of this bug. ***
Comment 14 Hasse 2002-11-26 07:46:56 PST
*** Bug 152819 has been marked as a duplicate of this bug. ***
Comment 15 jg 2002-11-26 10:07:14 PST
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
Comment 16 Hasse 2002-11-28 07:42:11 PST
*** Bug 182185 has been marked as a duplicate of this bug. ***
Comment 17 Drew Devereux 2002-12-17 15:46:25 PST
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.
Comment 18 R.K.Aa. 2002-12-19 09:06:57 PST
*** Bug 185993 has been marked as a duplicate of this bug. ***
Comment 19 Jesse Ruderman 2002-12-27 20:19:21 PST
*** Bug 168403 has been marked as a duplicate of this bug. ***
Comment 20 R.K.Aa. 2003-01-11 09:00:11 PST
*** Bug 188676 has been marked as a duplicate of this bug. ***
Comment 21 R.K.Aa. 2003-01-14 23:59:38 PST
*** Bug 189159 has been marked as a duplicate of this bug. ***
Comment 22 Hoss 2003-01-15 00:27:01 PST
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.
Comment 23 JT Moree 2003-01-15 07:56:33 PST
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.
Comment 24 Brant Gurganus 2003-01-18 17:51:07 PST
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.
Comment 25 Jonadab the Unsightly One (Nathan Eady) 2003-01-19 05:28:46 PST
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.  
Comment 26 R.K.Aa. 2003-02-18 04:42:56 PST
*** Bug 193836 has been marked as a duplicate of this bug. ***
Comment 27 Hasse 2003-06-01 00:16:07 PDT
*** Bug 207777 has been marked as a duplicate of this bug. ***
Comment 28 rr_mozilla 2003-06-07 10:39:08 PDT
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!
Comment 29 timeless 2003-07-02 10:12:32 PDT
*** Bug 211414 has been marked as a duplicate of this bug. ***
Comment 30 Scott Gifford 2003-07-27 10:30:43 PDT
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.  :-)
Comment 31 Alfonso Martinez 2003-09-20 12:11:38 PDT
*** Bug 219777 has been marked as a duplicate of this bug. ***
Comment 32 Jon Henry 2003-10-21 09:14:29 PDT
*** Bug 222603 has been marked as a duplicate of this bug. ***
Comment 33 mozbugs 2003-11-27 00:53:59 PST
possible dupes:

bug 151157
bug 225971 (first comment in that report contains other bugs it may be duped to)
Comment 34 Andreas Kunz 2004-01-03 05:47:00 PST
*** Bug 225971 has been marked as a duplicate of this bug. ***
Comment 35 Andreas Kunz 2004-01-03 06:05:25 PST
*** Bug 151157 has been marked as a duplicate of this bug. ***
Comment 36 Andreas Kunz 2004-01-03 06:08:02 PST
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.
Comment 37 R.K.Aa. 2004-01-24 11:19:17 PST
*** Bug 232039 has been marked as a duplicate of this bug. ***
Comment 38 HJ 2004-01-24 16:16:55 PST
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?
Comment 39 WD 2004-01-28 08:02:51 PST
*** Bug 232426 has been marked as a duplicate of this bug. ***
Comment 40 R.K.Aa. 2004-02-14 05:41:06 PST
*** Bug 234308 has been marked as a duplicate of this bug. ***
Comment 41 Alfonso Martinez 2004-02-14 12:29:02 PST
*** Bug 234342 has been marked as a duplicate of this bug. ***
Comment 42 Jesse Ruderman 2004-02-14 13:51:08 PST
See also bug 234298, same bug for Firefox.
Comment 43 Peter 2004-02-14 17:40:09 PST
(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 .. )
Comment 44 Martyr 2004-02-19 16:12:02 PST
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.)
Comment 45 Met - Martin Hassman 2004-05-24 04:46:08 PDT
(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 46 Met - Martin Hassman 2004-05-24 05:23:06 PDT
Created attachment 149199 [details] [diff] [review]
Path - don't hide tabbrowser with toolbar=no
Comment 47 Met - Martin Hassman 2004-05-24 05:35:21 PDT
Comment on attachment 149199 [details] [diff] [review]
Path - don't hide tabbrowser with toolbar=no

Some tip for the sr ?
Comment 48 Samir L. Boulema 2004-05-25 12:55:04 PDT
*** Bug 234298 has been marked as a duplicate of this bug. ***
Comment 49 neil@parkwaycc.co.uk 2004-07-08 01:58:26 PDT
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.
Comment 50 Henry Goffin 2004-09-18 10:04:09 PDT
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.
Comment 51 chris hofmann 2004-09-28 21:18:07 PDT
ben, can you have a look to see if there is anything that we can do here without
undue risk or regression.
Comment 52 chris hofmann 2004-09-30 16:47:21 PDT
would need a good patch to try and take this for 1.0 at this point.
Comment 53 David Janes 2004-10-31 08:14:13 PST
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).
Comment 54 Jason Bassford 2004-10-31 15:05:05 PST
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...
Comment 55 Miguel Gaspar 2004-11-10 18:04:28 PST
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.
Comment 56 Aleksanteri Aaltonen 2004-11-12 14:32:16 PST
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?
Comment 57 Chris Smith 2004-11-13 01:31:44 PST
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...
Comment 58 Jason Bassford 2004-11-13 08:32:41 PST
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 59 Ian Neal 2004-11-24 15:02:14 PST
Comment on attachment 149199 [details] [diff] [review]
Path - don't hide tabbrowser with toolbar=no

Cancelling old sr request
Comment 60 Ian Neal 2004-11-25 18:07:53 PST
Created attachment 167072 [details] [diff] [review]
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.
Comment 61 neil@parkwaycc.co.uk 2004-11-26 06:03:42 PST
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...
Comment 62 Ian Neal 2004-11-26 07:26:02 PST
Created attachment 167118 [details] [diff] [review]
Patch v0.1a - tidier patch to show tabstrip only when more than one tab is open with toolbar=no

A slightly tidier patch that also makes the use of const/var and capitalisation
more consistent.
Comment 63 HJ 2004-11-26 07:57:42 PST
(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 64 neil@parkwaycc.co.uk 2004-11-26 08:47:55 PST
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.
Comment 65 HJ 2004-11-26 11:06:03 PST
(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?
Comment 66 Ian Neal 2004-11-28 10:51:35 PST
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.
Comment 67 Ian Neal 2004-11-28 10:54:59 PST
Created attachment 167271 [details] [diff] [review]
Tweak to navigator.js

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.
Comment 68 HJ 2004-11-28 16:10:59 PST
(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 ;)
Comment 69 Jason Bassford 2004-11-28 16:17:29 PST
> 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...
Comment 70 jag (Peter Annema) 2004-12-01 02:46:19 PST
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.
Comment 71 David Janes 2004-12-01 03:27:25 PST
(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.
Comment 72 Robert Hofmann 2004-12-03 03:21:28 PST
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

Comment 73 Peter 2004-12-03 04:18:00 PST
(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 .. 
Comment 74 Phil Ringnalda (:philor) 2004-12-12 15:46:03 PST
*** Bug 274353 has been marked as a duplicate of this bug. ***
Comment 75 Ian Neal 2005-01-03 09:49:34 PST
Created attachment 170162 [details] [diff] [review]
Unbitrotted combined tabstrip fix for tabbrowser.xml and navigator.js v0.1c

Combined patch, carrying forward r+ and requesting sr.
Comment 76 neil@parkwaycc.co.uk 2005-01-15 03:43:15 PST
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.
Comment 77 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2005-01-15 03:52:53 PST
(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).
Comment 78 Hasse 2005-01-24 11:42:42 PST
*** Bug 279460 has been marked as a duplicate of this bug. ***
Comment 79 Smokey Ardisson (offline for a while; not following bugs - do not email) 2005-01-29 00:39:06 PST
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.
Comment 80 Matthew Paul Thomas 2005-03-21 14:37:17 PST
(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.)
Comment 81 Benjamin Smedberg [:bsmedberg] 2005-04-22 05:35:25 PDT
belewfan, the blocking+ flags are for drivers.
Comment 82 Kevin Brosnan 2005-05-17 06:26:39 PDT
*** Bug 293857 has been marked as a duplicate of this bug. ***
Comment 83 Robin Monks 2005-06-08 06:42:29 PDT
*** Bug 296543 has been marked as a duplicate of this bug. ***
Comment 84 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2005-07-02 21:37:10 PDT
*** Bug 219777 has been marked as a duplicate of this bug. ***
Comment 85 neil@parkwaycc.co.uk 2005-07-03 11:24:16 PDT
(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.
Comment 86 Ian Neal 2005-07-03 14:30:44 PDT
Created attachment 188135 [details] [diff] [review]
Unbitrotted again patch v0.1d

Changes since v0.1c:
* Unbitrotted the parts of tabbrowser.xml that had changed
Comment 87 Ian Neal 2005-07-11 15:16:24 PDT
Created attachment 188982 [details] [diff] [review]
Alternate patch v0.1e

Changes since v0.1d:
* On toolbarless popup tabstrip always visible once additional tabs are opened
in popup even if they are closed again.
Comment 88 Ian Neal 2005-07-11 16:30:16 PDT
Created attachment 188990 [details] [diff] [review]
no toolbar.visible effect on remove patch v0.1f

Changes since v0.1e:
* window.toolbar.visible now has no affect on tab removal - so OS X widget does
not cause issues.
Comment 89 neil@parkwaycc.co.uk 2005-07-11 16:52:14 PDT
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?
Comment 90 Ian Neal 2005-07-11 17:21:15 PDT
Created attachment 188996 [details] [diff] [review]
no autohide var patch v0.1g (Checked in)

Changes since v0.1f
* Removed autohide var completely as not really needed

Carrying forward r= and requesting sr=
Comment 91 jag (Peter Annema) 2005-07-14 23:41:20 PDT
Comment on attachment 188996 [details] [diff] [review]
no autohide var patch v0.1g (Checked in)

Nice!
Comment 92 Ian Neal 2005-07-15 05:12:14 PDT
Comment on attachment 188996 [details] [diff] [review]
no autohide var patch v0.1g (Checked in)

Requesting approval for fairly low risk patch
Comment 93 Ian Neal 2005-07-15 06:00:10 PDT
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
Comment 94 Ian Neal 2005-07-15 14:49:42 PDT
Firefox version of this patch is covered by bug 243893
Comment 95 Stephen Donner [:stephend] 2005-08-10 03:22:21 PDT
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.
Comment 96 JT Moree 2006-03-29 06:48:05 PST
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. 
Comment 97 Ian Neal 2006-03-31 12:23:10 PST
You are correct, this has regressed -> reopening
Comment 98 Ian Neal 2006-03-31 12:53:58 PST
Regression window is between BuildIDs 2005120510 and 2005120611, likely candidate is checkin for Bug 105885
Comment 99 Ian Neal 2006-03-31 13:56:11 PST
Created attachment 216869 [details] [diff] [review]
Regression fix due to bug 105885 checkin v0.2 (Checked in trunk & 1.8 & 1.8.0 branch)

This patch:
* Removes chromeclass-toolbar class from tabbrowser-strip
Comment 100 Ian Neal 2006-03-31 15:20:40 PST
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 101 Ian Neal 2006-03-31 15:24:07 PST
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 102 Robert Kaiser (not working on stability any more) 2006-03-31 15:39:24 PST
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 103 Ian Neal 2006-03-31 15:44:14 PST
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 104 Robert Kaiser (not working on stability any more) 2006-04-04 06:20:08 PDT
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
Comment 105 Robert Kaiser (not working on stability any more) 2006-04-04 06:27:46 PDT
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 ;-)
Comment 106 Robin Monks 2006-04-04 06:46:14 PDT
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 107 Ian Neal 2006-04-04 15:11:53 PDT
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
Comment 108 Tracy Walker [:tracy] 2006-05-05 13:42:50 PDT
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
Comment 109 Stefan [:stefanh] 2006-05-07 11:51:49 PDT
(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" ;-) 
Comment 110 Tracy Walker [:tracy] 2006-05-07 19:02:01 PDT
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.  
Comment 111 Stefan [:stefanh] 2006-05-08 06:11:54 PDT
(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...
Comment 112 Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-05-08 08:10:15 PDT
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!
Comment 113 Tracy Walker [:tracy] 2006-05-08 10:02:27 PDT
gavin just pointed me to the firefox version of this bug.  bug 243893.   I'll reset to fixed1.8.0.4
Comment 114 Tracy Walker [:tracy] 2006-05-24 08:48:49 PDT
Ah, so the Firefox specific keywords actually do not belong here because there is a dedicated bug for Fx.

Note You need to log in before you can comment on or make changes to this bug.