Closed
Bug 633788
Opened 14 years ago
Closed 14 years ago
"closing last tab" inconsistency between main browser window and panorama
Categories
(Firefox Graveyard :: Panorama, defect, P2)
Tracking
(blocking2.0 -)
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: florian.neubauer.neuroscience, Assigned: raymondlee)
References
Details
(Keywords: regression)
Attachments
(1 file, 3 obsolete files)
5.24 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
In the main window the last tab cannot be closed. In panorama the last tab can be closed and the browser closes quite unexpectedly. Behavior of main window should copied over to panorama.
Reproducible: Always
Steps to Reproduce:
1. Try to close last tab in main browser window --> not possible.
2. Try to close last tab in panorama --> possible, and browser closes.
Actual Results:
browser closes after closing last tab in panorama
Expected Results:
last tab cannot be closed, as in main window of the browser
Between FF4-beta-9 and beta-11 there was progress towards more consistency between the main window and panorama. E.g. the last tab group cannot be closed in panorama anymore. In this spirit you should stick with the design decision made for the main browser window: One cannot close the last tab. Just copy this decision over 1:1 to panorama and make it impossible to close the last tab. Then the surprising and unexpected event does not happen anymore that the browser closes after closing the last tab.
Reporter | ||
Comment 1•14 years ago
|
||
Implementing this behavior in panorama would have a very positive side effect: If the last tab cannot be closed, you do not need to handle the case anymore what should happen if the last tab group is closed - because it simply could not be closed anymore either. Just as it is already implemented for the case that there are app tabs open. In turn, if you stick with the current decision for the case that there are no app tabs open, which means, that the last tab group actually can be closed and this action ends with an empty tab in the main window, then - again for consistency - closing the last group also should be possible in the case that there are app tabs present, in this case one of the app tabs could be the tab you land in, or - for consistency - an empty tab next to the app tabs. However, I really think that not being able to close the last tab group and not being able to close the last tab whether there are app tabs or not would be the most consistent solution.
Updated•14 years ago
|
Version: unspecified → Trunk
Comment 2•14 years ago
|
||
This is a regression.
Blocks: 627096
Severity: enhancement → normal
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Keywords: regression
Priority: -- → P2
Updated•14 years ago
|
blocking2.0: ? → -
Comment 3•14 years ago
|
||
Up until recently (I suppose), Panorama would put you into a new blank tab if you closed the last tab. I propose we fix whatever broke that, in the Fx4 time frame. Post Fx4 we can consider the additional UX suggestions in this bug.
Updated•14 years ago
|
Keywords: regressionwindow-wanted
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → raymond
Assignee | ||
Comment 4•14 years ago
|
||
Attachment #513397 -
Flags: review?(ian)
Assignee | ||
Comment 5•14 years ago
|
||
Uploaded a wrong patch
Attachment #513397 -
Attachment is obsolete: true
Attachment #513398 -
Flags: review?(ian)
Attachment #513397 -
Flags: review?(ian)
Comment 6•14 years ago
|
||
Comment on attachment 513398 [details] [diff] [review]
v1
Looks good, except I think the new tab should go into the closing tab's parent group (if any, otherwise use the logic you have).
Attachment #513398 -
Flags: review?(ian) → review-
Updated•14 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•14 years ago
|
||
Attachment #513398 -
Attachment is obsolete: true
Attachment #513754 -
Flags: review?(ian)
Assignee | ||
Comment 8•14 years ago
|
||
Comment on attachment 513754 [details] [diff] [review]
v2
Passed try
http://tbpl.mozilla.org/?tree=MozillaTry&rev=8f1ff63d4c47
Comment 9•14 years ago
|
||
Comment on attachment 513754 [details] [diff] [review]
v2
Thanks!
Attachment #513754 -
Flags: review?(ian) → review+
Assignee | ||
Updated•14 years ago
|
Attachment #513754 -
Flags: approval2.0?
Comment 10•14 years ago
|
||
Comment on attachment 513754 [details] [diff] [review]
v2
a=beltzner
Attachment #513754 -
Flags: approval2.0? → approval2.0+
Comment 11•14 years ago
|
||
Attachment #513754 -
Attachment is obsolete: true
Updated•14 years ago
|
Keywords: regressionwindow-wanted → checkin-needed
Comment 12•14 years ago
|
||
Comment 13•14 years ago
|
||
Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110224 Firefox/4.0b13pre
Verified issue and it's no longer present in latest build.
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•