Closed
Bug 156082
Opened 22 years ago
Closed 18 years ago
Don't hide the tab bar when clicking the close box (pref for showing single tab ["Hide tab bar when only one tab is open"] is ignored)
Categories
(SeaMonkey :: UI Design, defect, P5)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
FIXED
seamonkey1.1beta
People
(Reporter: jmd, Assigned: csthomas)
References
(Blocks 1 open bug)
Details
(Keywords: fixed-seamonkey1.1b)
Attachments
(1 file, 2 obsolete files)
1.49 KB,
patch
|
jag+mozilla
:
review+
neil
:
superreview+
Biesinger
:
approval-seamonkey1.1b+
|
Details | Diff | Splinter Review |
Don't hide the tab bar when clicking the close box Bug 150099's 'fix' makes absolutely no sense and is "fundamentally counterintuitive, producing results that cannot" possibly "be predicted or expected by the user" See bug 150099 comment 28
Reporter | ||
Comment 1•22 years ago
|
||
Nominating for the same things the original bug had. CC'ing mpt (sorry chap), but maybe he can properly explain why this just can't be, if it isn't obvious enough.
Comment 2•22 years ago
|
||
-> UI design, cc'ing Lori.
Assignee: jaggernaut → mpt
Component: Tabbed Browser → User Interface Design
QA Contact: sairuh → zach
Comment 3•22 years ago
|
||
Man this was a bad idea. So I click close on my tab browser and the only way to get it back is to open a new tab and then close that tab? Bad idea. The close button shouldn't even be there if I have the browser set to always display the tab bar, or at LEAST if I click close when I have that pref set, it should change the pref so that when I go back into preferences, I can turn it back on. As it is, I have no tab bar and the pref says I should. Figure that out.
Comment 4•22 years ago
|
||
Use View -> Show/Hide -> Tab Bar to show the tab bar again. The pref is about auto-hiding, the close box forcibly hides the tab bar when the auto-hide pref is off. I tried not to reuse the pref, because if you do, there's another case where you'll get confusion, which is when you've used the close box to hide the tab bar, open a second tab and then later close that second tab, the tab bar will automatically hide (not what's expected), leaving you with no easy way to get the tab bar to stay visible (other than going back to the prefs). The problem here is that there are two models to hide the tab bar, one that hides it automatically when there's one tab left, another where the user hides it, and their overlap confuses people who've previously only been exposed to the auto-hide feature.
Assignee: mpt → lorikaplan
Comment 5•22 years ago
|
||
*** Bug 159191 has been marked as a duplicate of this bug. ***
*** Bug 182000 has been marked as a duplicate of this bug. ***
*** Bug 183475 has been marked as a duplicate of this bug. ***
*** Bug 183473 has been marked as a duplicate of this bug. ***
*** Bug 183422 has been marked as a duplicate of this bug. ***
Comment 10•22 years ago
|
||
jag: "The problem here is that there are two models to hide the tab bar ... and their overlap confuses people who've previously only been exposed to the auto-hide feature." The problem is that ordinary users lose the tab bar and never get it back. I've seen it on their Netscape 7 installs. If they can't find the tab bar, then tabbed browsing effectively doesn't exist in their browser. "Use View -> Show/Hide -> Tab Bar" I doubt many users will look until they find that command, two levels deep in a menu, esp. when they don't necessarily know what this new feature does.
Comment 11•22 years ago
|
||
*** Bug 168421 has been marked as a duplicate of this bug. ***
Comment 12•22 years ago
|
||
Bug 168421, which I just duped, points out that this bug occurs with ctrl+f4 as well as a click on the close box.
Comment 13•22 years ago
|
||
*** Bug 187871 has been marked as a duplicate of this bug. ***
Comment 14•22 years ago
|
||
*** Bug 188267 has been marked as a duplicate of this bug. ***
Comment 15•22 years ago
|
||
This is my observation of the issue: [1.2.1 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130] When you click "x" on the tab bar with one tab open, the tab bar closes but the page stays up. After that, any browser windows that you open don't show the tab bar. I made sure that "Hide the tab bar when only one tab is open" was DEselected in preferences. Yet when only one tab is open, the tab bar is still hidden. The bug, I guess, is that the preferences don't reflect the actual behavior in this case. A more intuitive behavior might be this: When you click "x" with only one tab open, the tab you were viewing goes away, and a new tab "(Untitled)" is opened. That is, the tab currently created by File->New->Navigator Tab. This would seem more consistent to me because the other toolbars are all hidden/shown through the View menu (and not by clicking directly on them.) If you want to actually hide the tab bar, you should do so with the view menu. If this doesn't seem intuitive to everyone, then perhaps a preference could be added: When only one tab is open: "x" hides the tab bar OR "x" closes the last tab and opens a new tab
Comment 16•22 years ago
|
||
> When only one tab is open:
> "x" hides the tab bar OR
> "x" closes the last tab and opens a new tab
"x" is not the right terminology to use. First, there are other "x" buttons
all over the place, depending on your theme. The stop button, for example.
Second, the close-tab buttom may not be an "x" at all, depending on theme.
Additionally, Ctrl-W does the same thing (or clover-W on Mac). Also, what
happens if both of those are checked? Shouldn't they be mutually exclusive?
Perhaps something more along these lines:
Attempting to close the last tab
(*) replaces the page with a blank one
( ) hides the tab bar
( ) does nothing
(I marked about:blank as default because I listed it first, but it doesn't
actually matter what the default is; people who don't change prefs don't
use tabs, either.)
I could also live with following the pref as it stands now and only hiding
the tab bar when "Hide the tab bar when only one tab is open" is checked,
or when the user hides it under Show/Hide in the View menu. If we go that
way, the close-tab button should be disabled when only one tab is showing,
and Classic and Modern should be fixed to have it appear disabled ("greyed
out") when [disabled=true], just like other buttons (back, forward, &c).
(Whatever Modern and Classic both do, third-party themes eventually follow.)
This really would be what I would think would be right -- but the preference
approach above would be acceptable also, and lets us get away without adding
a disabled state to the button.
Comment 17•22 years ago
|
||
This is a bug, the tab bar 'x' means close, nobody can dispute that. Ctrl-w means close tab, nobody can dispute that. They should do the same thing, simple as that. If we started adding 'options' for anything that didn't work as expected, the user would be swamped and give up! If the user doesn't want the tab bar, they can use the existing options to do so. C'mon, there are dozens of bugs reported on the same problem, why can't someone spend 5min fixing the 'x' to ctrl-w? You won't even accept the bug? won't even commit to a target milestone? 20+ppl in the CC list can't be hallucinating.
Comment 18•21 years ago
|
||
This is definitely a bug. Here's some behaviour which to my mind proves it. With the hide tab bar with one tab open pref not set, try opening a new window then click the close tab. Tab bar disappears as we know. Now close your window and open another new one ... hey where's the tab bar!!! This is a case of the pref being blatantly ignored. It's also a case of consistency. Why should the button suddenly do something different just because there is only one tab left and more than that it does something I thought I asked to never happen. The button should either not be shown with one tab or close the tab leaving no tabs (like word) or leave a blank tab. Any will do, but the current behaviour is wrong!
Comment 19•21 years ago
|
||
*** Bug 205626 has been marked as a duplicate of this bug. ***
Comment 20•21 years ago
|
||
Currently: Window closes with: Ctrl-W, File -> Close Tab. Tab bar hides with: Tab bar close (X). Nothing (inactive): Context menu close. Right now, I would be much happier if everything did the same thing. Inconsistency sucks. Even if every close method closed the tab bar (which I *don't* think should be the case) I'd prefer things to what we have now. Then, at least, we could address every situation with one single patch.
Comment 22•21 years ago
|
||
*** Bug 222109 has been marked as a duplicate of this bug. ***
Comment 23•21 years ago
|
||
*** Bug 220791 has been marked as a duplicate of this bug. ***
Comment 24•21 years ago
|
||
*** Bug 209903 has been marked as a duplicate of this bug. ***
Comment 25•21 years ago
|
||
reassigning bug to current owner/QA of tabbed browser component.
Assignee: lorikaplan → tabbed-browser
Updated•20 years ago
|
Flags: blocking1.7b? → blocking1.7b-
Comment 26•20 years ago
|
||
*** Bug 238198 has been marked as a duplicate of this bug. ***
Comment 27•20 years ago
|
||
*** Bug 245786 has been marked as a duplicate of this bug. ***
Comment 28•20 years ago
|
||
OK. My idea is: - When there are more than one tab, the button is [x] and close the current tab. - When there is only one tab, the button changes to something different (let's say [/] for example) and hide the tab bar. I think it's good.
Comment 29•20 years ago
|
||
What about middle-click to close the last open tab?
Comment 30•20 years ago
|
||
(In reply to comment #28) > - When there is only one tab, the button changes to something different (let's > say [/] for example) and hide the tab bar. I disagree with this suggestion. From a usability standpoint I think it is confusing for the user when a menu item or button at a specific location changes function. That is why menu and dialog items that are not applicable are greyed out instead of removed. My suggestion would therefor be: - many tabs: [X] closes the currently shown tab. - 1 tab: [X] closes the currently shown tab. I feel that logic dictates that the window should be closed as well. Hiding the tab bar defies logic.
Comment 31•20 years ago
|
||
I agree with comment #30. I think that the best option is to close que whole window, as it happens if one uses the keyboard shortcut (Ctrl W). The second best would be to simply disable the button when there's only one tab open.
Comment 32•20 years ago
|
||
A while ago on the newsgroups this subject was discussed. IIRC (big if) the verdict was about equally split between closes the tab, leaves no tabs open, closes the tab, opens a new tab with a blank page, and closes the window. I see things as follows: when I click the close tab button, I am expecting the tab to close /and/ I am expecting the tab behind it to be revealed. That's what happens every other time. This is a slightly special case, since there is no tab behind it to be revealed; therefore, logic dictates it should be closed and nothing else revealed, but usability dictates that another tab should be opened since having no tabs open is useless and since in every other case I am expecting another tab to be there. I definitely do not expect the window to be closed. If I wanted the window to close, I would use the button the OS provides. This is easier (it's nearly always in a corner of the screen if the window is maximized or in an area of higher contrast and therfore easier to pick out if the window is not) and is the standard way of doing things. Also, if the tab button closes the window, then /every single time/ I want to close a tab, I have to think "Will this close the whole program?" since I don't want the whole program closed, I just want that tab closed. As minor as that is to check, doing it every single time will get quite annoying.
Comment 33•20 years ago
|
||
I believe the code causing this would be one of these: http://lxr.mozilla.org/mozilla/search?string=removeCurrentTab , most likely http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/tabbrowser.xml#849 and/or http://lxr.mozilla.org/mozilla/source/xpfe/global/resources/content/bindings/tabbrowser.xml#959 but don't take my word for it.
Comment 34•20 years ago
|
||
(In reply to comment #31) > I agree with comment #30. > I think that the best option is to close que whole window, as it happens if one > uses the keyboard shortcut (Ctrl W). The second best would be to simply disable > the button when there's only one tab open. I fully agree. where "disable the button" means "gray out the button"
Comment 35•20 years ago
|
||
If you want to debate the merits of bugs, including advocating one resolution or another, please use a forum such as newsgroups or mozillazine forums. Bugzilla isn't the place for it.
Updated•20 years ago
|
Flags: blocking-aviary1.0?
Updated•20 years ago
|
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Comment 36•20 years ago
|
||
Just an fyi for those who are waiting for this (even more so because this bug isnt assigned yet), there is an extension that fixes this bug: http://update.mozilla.org/extensions/moreinfo.php?id=175&vid=334&category=
Comment 37•20 years ago
|
||
Unfortunately, that XPI doesn't install for me. I go to install it, and I'm told "install script not found" - whatever that means... (7/23-07 under XP.) I do like the fact that somebody's working on an XPI, however. If I'm not mistaken, it makes it fairly simple to convert it into an actual patch.
Comment 38•20 years ago
|
||
fmannino: why do you remove the MINUS flag on the blocking-aviary1.0? The decision was made by the appropriate person and since his decision on July 3, no additional work has been done on this bug? Setting the minus flag back again. If you DO want Blake to reconsider, than add some comments as to why you re-request a blocking flag.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Comment 39•20 years ago
|
||
Clicking that button is actually closing the tab, but the semantics behind it is more about stopping viewing the currently displayed page. When a user clicks that button they are most likely meaning, "I'm done with this page. I don't want to view it anymore. Get rid of it." Therefore behaviour should be: 2+ tabs = stop displaying the current page (close the tab, show the next tab in order) 1 tab = stop displaying the current page (replace the current page with about:blank) The button should not ever be overloaded with behaviour to remove the tab bar. The correct place to determine if the tab bar is shown or not is a menu and/or preferences screen. If the tab close button is going to be disabled at any time, it should only be when there is only 1 tab left, AND that tab is displaying about:blank. Users WANT to be able to stop viewing that last page.
Comment 40•20 years ago
|
||
Comment 39: that seems a good solution. Other proposed solutions do other things than closing the page, or create different functionalities for the same button. Also, this does not modify the visibility of the tab bar. Can anyone think of a better one?
Comment 41•20 years ago
|
||
I fully agree to comment #39 where > 2+ tabs = stop displaying the current page > (close the tab, show the next tab in order) "the next tab in order" should be "in chronological order", i.e., in order they wer viewed last.
Comment 42•20 years ago
|
||
Comment 41: that would be another bug which requires a lot of discussion. Something like "go to the last viewed tab when current tab is closed".
Comment 43•20 years ago
|
||
(In reply to comment #42) > Comment 41: that would be another bug which requires a lot of discussion. > Something like "go to the last viewed tab when current tab is closed". you're right: this is bug 105722
Comment 44•20 years ago
|
||
same bug for firefox (now fixed): bug 248987
Comment 45•20 years ago
|
||
this is fixed in bug 248987. the decision there was to about:blank the last tab if the user clicked the [x] to close the last tab. marking this a dupe since the fix was attached there. *** This bug has been marked as a duplicate of 248987 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Comment 46•20 years ago
|
||
Bug 248987 is Firefox specific and has nothing to do with the Mozilla browser - which this bug is filed again. Reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 47•20 years ago
|
||
This is the approved patch I wrote for Firefox in bug 248987, modified for Mozilla. I don't have Mozilla to check that it works, but I dont see why it wouldn't.
Comment 48•20 years ago
|
||
> this.loadURI("about.blank");
It's about:blank
Comment 50•20 years ago
|
||
Comment on attachment 160372 [details] [diff] [review] Blanks last tab instead of hiding the Tab Bar if "Hide Tab Bar" option is unticked requesting r/sr for your patch.
Attachment #160372 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #160372 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 51•20 years ago
|
||
Comment on attachment 160372 [details] [diff] [review] Blanks last tab instead of hiding the Tab Bar if "Hide Tab Bar" option is unticked Erh, you shouldn't have to check the autohide pref, if that is set to true, with only one tab left the bar is hidden and there's no close box to click. This reveals the dead code resulting from this patch, namely the code that would force the tab bar to hide. And with that gone the rest of the code dealing with browser.tabs.forceHide can also be removed / amended. That said, let me think about the desired effect of this patch. I'll get back to you on this.
Attachment #160372 -
Flags: superreview?(neil.parkwaycc.co.uk) → superreview-
Comment 52•20 years ago
|
||
(In reply to comment #51) >This reveals the dead code resulting from this patch, namely the code that >would force the tab bar to hide. And with that gone the rest of the code >dealing with browser.tabs.forceHide can also be removed / amended. Does that include View Show/Hide Tab Bar?
Updated•20 years ago
|
Attachment #160372 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 53•20 years ago
|
||
As far as I can see, this patch should be as follows. var l = this.mTabContainer.childNodes.length; if (l == 1) { if (this.mPrefs.getBoolPref("browser.tabs.autoHide")) { // this should only ever happen if the pref was changed while // there was only a single tab displayed. this.setStripVisibilityTo(false); } else { // blank the last tab //TODO: remove tab history this.loadURI("about:blank"); } return; } This will hide the tab-bar if autohide is true, and just blank it otherwise. We don't want to force autohide to true at any time.
Comment 54•19 years ago
|
||
*** Bug 304775 has been marked as a duplicate of this bug. ***
Comment 55•19 years ago
|
||
Cross-reference to code shown in bug 236721 comment 21. Notes: * You always want to do loadURI("about:blank") if there is only one tab left open. How the user has the tab-hiding set up is simply irrelevant to this, and the current code gets this wrong (i.e. if you only have one tab left open, and you don't have autohide on, then currently it won't close the current tab, which is simply wrong). * You always want to purge the session history too (see code at above cross reference for how to do this). * Brodie may well be correct about not setting the forceHide preference. I haven't looked into this, and simply rearranged the existing code when it came to this. So perhaps the 'setBoolPref("browser.tabs.forceHide", true)' line should be deleted.
Comment 56•19 years ago
|
||
See my original comment 20. Having about:blank when clicking on the last tab replaces one set of inconsistent results with yet another, making the overall situation no better than before. If that is the final solution, then should a further bug be filed so that Ctrl-W gives you about:blank also? (Although, I do note that you can now use the context menu on the last tab to get the same results as the tab close button - it's no longer greyed out. I'm not sure when that behaviour changed, but it's a step in the right direction of consistency.)
Comment 57•19 years ago
|
||
Changing module to mozilla application suite, since firefox already has a fix (via bug 248987)
Component: Tabbed Browser → General
Product: Core → Mozilla Application Suite
Comment 58•19 years ago
|
||
*** Bug 313416 has been marked as a duplicate of this bug. ***
Comment 59•19 years ago
|
||
*** Bug 322326 has been marked as a duplicate of this bug. ***
Comment 60•18 years ago
|
||
*** Bug 326395 has been marked as a duplicate of this bug. ***
Comment 61•18 years ago
|
||
as bug #326395 as been marked a duplicate of this one which is more than three years old, I re-post its decription here as it doesn't seems to me that it's the same. submited bug #326395 Opened: 2006-02-08 04:29 User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0 on the last release of seamonkey I installed, it's impossible to close the first tab even when other tabs are opened. When it's the only tab this action hides the tab bar Reproducible: Always Steps to Reproduce: 1.a web page 2.open another page in the second tab 3. try to close the first tab
Comment 62•18 years ago
|
||
I've just tried with a new profile and all is working now, even other problems on bugs I've submited are gone, I'm going to reinstall one by one the extensions I have in my profile to try to identify the problematic one
> as bug #326395 as been marked a duplicate of this one which is more than three
> years old, I re-post its decription here as it doesn't seems to me that it's
> the same.
>
> submited bug #326395 Opened: 2006-02-08 04:29
>
> User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.8.0.1)
> Gecko/20060130 SeaMonkey/1.0
> Build Identifier: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.8.0.1)
> Gecko/20060130 SeaMonkey/1.0
>
> on the last release of seamonkey I installed, it's impossible to close the
> first tab even when other tabs are opened.
> When it's the only tab this action hides the tab bar
>
>
> Reproducible: Always
>
> Steps to Reproduce:
> 1.a web page
> 2.open another page in the second tab
> 3. try to close the first tab
>
Comment 63•18 years ago
|
||
maybe Bug 154849 is an duplicate?
Assignee: tabbed-browser → general
Status: REOPENED → NEW
QA Contact: zach → general
Summary: Don't hide the tab bar when clicking the close box → Don't hide the tab bar when clicking the close box (pref for showing single tab ["Hide tab bar when only one tab is open"] is ignored)
Comment 64•18 years ago
|
||
*** Bug 154849 has been marked as a duplicate of this bug. ***
Comment 65•18 years ago
|
||
*** Bug 322326 has been marked as a duplicate of this bug. ***
Comment 66•18 years ago
|
||
tabbed browser, no?
Assignee: general → nobody
Component: General → Tabbed Browser
Product: Mozilla Application Suite → Core
QA Contact: general → tabbed-browser
Assignee | ||
Comment 67•18 years ago
|
||
Taking... this is low priority for me so feel free to swipe the bug and fix it yourself :).
Assignee: nobody → cst
Priority: -- → P5
Assignee | ||
Comment 68•18 years ago
|
||
Same as the Firefox implementation.
Attachment #160372 -
Attachment is obsolete: true
Attachment #233414 -
Flags: superreview?(neil)
Attachment #233414 -
Flags: review?(jag)
Assignee | ||
Updated•18 years ago
|
Whiteboard: [cst: r?j sr?n]
Updated•18 years ago
|
Attachment #233414 -
Flags: review?(jag) → review+
Assignee | ||
Updated•18 years ago
|
Whiteboard: [cst: r?j sr?n] → [cst: r+ sr?n]
Comment 69•18 years ago
|
||
Comment on attachment 233414 [details] [diff] [review] blank last tab This will cause me dataloss, because I'm used to X hiding the tab bar... > var l = this.mTabs.length; >- if (l == 1) { >- // hide the tab bar >- this.mPrefs.setBoolPref("browser.tabs.forceHide", true); >- this.mStrip.collapsed = true; >- return; >- } Move the var l to where you use it. sr=me with this fixed.
Attachment #233414 -
Flags: superreview?(neil) → superreview+
Comment 70•18 years ago
|
||
The new behaviour is inconsistent to the behaviour of Ctrl+W. If you press Ctrl+W on the last tab and browser.tabs.autoHide is set to true, the browser window gets closed and I expect the same from the close box.
Assignee | ||
Comment 71•18 years ago
|
||
(In reply to comment #70) > The new behaviour is inconsistent to the behaviour of Ctrl+W. If you press > Ctrl+W on the last tab and browser.tabs.autoHide is set to true, the browser > window gets closed and I expect the same from the close box. > Hmmm... Firefox doesn't let you quit with Ctrl+W. Jag? Neil? Do you think we should make ^w match the behavior of clicking the "X" like Firefox?
Assignee | ||
Comment 72•18 years ago
|
||
(In reply to comment #71) > (In reply to comment #70) > > The new behaviour is inconsistent to the behaviour of Ctrl+W. If you press > > Ctrl+W on the last tab and browser.tabs.autoHide is set to true, the browser > > window gets closed and I expect the same from the close box. > > > > Hmmm... Firefox doesn't let you quit with Ctrl+W. Jag? Neil? Do you think we > should make ^w match the behavior of clicking the "X" like Firefox? And should it be based on the pref? (i.e. should ctrl+w close the browser if you choose to hide the tab bar?)
Whiteboard: [cst: r+ sr?n] → [cst: figure out ctrl+w]
Comment 73•18 years ago
|
||
^W should always close the window if only one tab is left.
Assignee | ||
Comment 74•18 years ago
|
||
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 20 years ago → 18 years ago
Resolution: --- → FIXED
Whiteboard: [cst: figure out ctrl+w] → [cst: request a= after baking on trunk]
Assignee | ||
Updated•18 years ago
|
Component: Tabbed Browser → XP Apps: GUI Features
Product: Core → Mozilla Application Suite
Target Milestone: --- → seamonkey1.1beta
Assignee | ||
Updated•18 years ago
|
Attachment #233414 -
Flags: approval-seamonkey1.1a?
Updated•18 years ago
|
Attachment #233414 -
Flags: approval-seamonkey1.1a? → approval-seamonkey1.1a+
Comment 75•18 years ago
|
||
Comment on attachment 233414 [details] [diff] [review] blank last tab changing to 1.1b as alpha was released
Attachment #233414 -
Flags: approval-seamonkey1.1a+ → approval-seamonkey1.1b+
Assignee | ||
Updated•18 years ago
|
Keywords: fixed-seamonkey1.1b
Assignee | ||
Updated•18 years ago
|
Whiteboard: [cst: request a= after baking on trunk]
Comment 76•18 years ago
|
||
(In reply to comment #71) > Hmmm... Firefox doesn't let you quit with Ctrl+W. Jag? Neil? Do you think we > should make ^w match the behavior of clicking the "X" like Firefox? On single tab, with tab bar shown, more than being inconsistent with FireFox (which might be our choice.?!.), (In reply to comment #73) > ^W should always close the window if only one tab is left. SeaMonkey has an issue in the File menu: it reads "Close Tab / Ctrl+W" and "Close Window / Ctrl+Shift+W"; but, while the tab bar "X" closes the tab, Ctrl-W or its menu item closes the window :-( I believe the FireFox behaviour (== do what the menu says) is what we want too on this point !?
Comment 77•18 years ago
|
||
(In reply to comment #76) >SeaMonkey has an issue in the File menu: >it reads "Close Tab / Ctrl+W" and "Close Window / Ctrl+Shift+W"; >but, while the tab bar "X" closes the tab, >Ctrl-W or its menu item closes the window :-( Actually SeaMonkey always used to do this when the tabbar was visible... I'd prefer (in a separate bug) to make the menuitems track the actions.
Comment 78•18 years ago
|
||
I filed bug 351428 about comment 77 (and comment 72).
Comment 79•18 years ago
|
||
Wouldn't it be more logical to grey out the "Close Tab" option and not react on Ctrl+W when there is only one tab without tab bar? It doesn't seem right that closing the last tab should close the entire window, there's another option for that.
Comment 80•18 years ago
|
||
Ctrl+W closes the window everywhere else. It was only changed for tabbrowser because it was thought more useful for people using tabs instead of windows.
Comment 81•18 years ago
|
||
Not in win32 MDI windows IIRC (Now, do we consider tabbrowser windows pseudo-MDI?). Also, and again IIRC (and FWIW ;)) this was changed in IE7 and NS8.
Comment 82•18 years ago
|
||
We have two categories of users. Some never use tabs and never will. For them, we have to make Ctrl+W close the window like it does (or should do, at least) everywhere else *in SeaMonkey* while for those people who have migrated from windows to tabs we need Ctrl+W to close the current tab instead.
Comment 83•18 years ago
|
||
In Fx, Accel+W closes the window unless "Always show the tab bar" is ticked, in which case we destroy-and-create the first tab like the patch here does.
Comment 84•18 years ago
|
||
I don't think that would be right. What I could live with is that pressing Ctrl+W would close the window if the tab bar is hidden (in SeaMonkey there are three reasons that this could be the case.)
Comment 85•18 years ago
|
||
yeah, ugh, we do close popup windows on Accel+W regardless of the pref.
Comment 86•18 years ago
|
||
I guess the "Close Tab" in the tab context menu should always be enabled?
Comment 87•18 years ago
|
||
(In reply to comment #86) > I guess the "Close Tab" in the tab context menu should always be enabled? > Please!
You need to log in
before you can comment on or make changes to this bug.
Description
•