Closed Bug 579869 Opened 14 years ago Closed 14 years ago

Half of a App Tab Covers or is Covered by Part of the First Normal Tab, the New Tab Button or Other App Tabs after it is reopened

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 4.0b4
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: Ryuji, Assigned: dao)

References

Details

(Keywords: relnote)

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100718 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100718 Minefield/4.0b2pre

When A app Tab is closed and Restored, half of it when restored is covered by the first normal tab.

Reproducible: Always

Steps to Reproduce:
1. Open A Few Tab
2. In one of the tab go any web site you want and turn it into a App Tab
3. The App Tab is the most left tab now. 
4. Close the App tab by right clinking tab bar and selecting Close tab with your mouse
5. Right clink tab bar and select Undo Close Tab
6. App Tab is restored
7. You see that 1/2 of the restored App tab is covered by the first normal Tab
Actual Results:  
1/2 of the Restored App Tab is covered by the First Normal Tab

Expected Results:  
No part of the Restored App Tab is covered by the First Normal Tab
Initially in Step 1, Do not open more than 13 tabs. Or else You will not get the error. 

If you have seen Bug 579868, follow that STR will also get this error.
Blocks: pinnedtabs
Attached image App tab error
Component: General → Tabbed Browser
QA Contact: general → tabbed.browser
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Half of the App Tab is covered by the First Normal Tab when The Closed App Tab is restored.(provided that Total Normal Tabs is less than 14) → Half of the rightmost App Tab is covered by the First Normal Tab after it is reopened(Provided Total Normal Tabs is less than 14)
This is also easily seen by creating an App-tab, entering Private-browsing, and exiting again.. App-tab will overlap the 1st tab.
Requesting to block beta 3, since beta 2 is going to release soon.
Component: Tabbed Browser → Session Restore
QA Contact: tabbed.browser → session.restore
OS: Windows 7 → All
Hardware: x86 → All
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #459842 - Flags: review?(gavin.sharp)
Blocks: 563730, 579852
No longer blocks: pinnedtabs
Component: Session Restore → Tabbed Browser
QA Contact: session.restore → tabbed.browser
Attachment #459842 - Attachment description: patch → Skip the tab opening animation if the new tab has been pinned
If you create a new tab next to the covering app tab then turn that new tab into an app tab, the covering error goes away.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b2) Gecko/20100720 Firefox/4.0b2
Summary: Half of the rightmost App Tab is covered by the First Normal Tab after it is reopened(Provided Total Normal Tabs is less than 14) → Half of a App Tab covers the First Normal Tab, the New Tab Button or Other App Tabs after it is reopened
Summary: Half of a App Tab covers the First Normal Tab, the New Tab Button or Other App Tabs after it is reopened → Half of a App Tab Covers or is Covered by Part of the First Normal Tab, the New Tab Button or Other App Tabs after it is reopened
Comment on attachment 459842 [details] [diff] [review]
Skip the tab opening animation if the new tab has been pinned

>diff --git a/browser/base/content/tabbrowser.xml b/browser/base/content/tabbrowser.xml

>             if (aSkipAnimation ||
>                 this.tabContainer.getAttribute("overflow") == "true") {
>               t.setAttribute("fadein", "true");
>               setTimeout(function (tabContainer) {
>                 tabContainer._handleNewTab(t);
>               }, 0, this.tabContainer);
>             } else {
>-              setTimeout(function () { t.setAttribute("fadein", "true"); }, 0);
>+              setTimeout(function (tabContainer) {
>+                if (t.pinned)
>+                  tabContainer._handleNewTab(t);
>+                else
>+                  t.setAttribute("fadein", "true");
>+              }, 0, this.tabContainer);
>             }

This needs to be handled in the timeout rather than in the earlier check because sessionrestore pins the tab right after it's added, presumably? I wonder whether we should instead allow creating tabs as pinned...
Maybe, but it seems that we should handle pinTab(addTab()) either way.
This will happen with 8 tabs as well - but I'm working at 1440x900.
No longer blocks: 579852
blocking2.0: --- → ?
Blocking+ for janky-ui.
blocking2.0: ? → betaN+
Just for info purposes this happens to me when I come out of Private Browsing mode as well - just a reminder for QA to verify that scenario as well when the bug is fixed.
Attachment #459842 - Flags: review?(gavin.sharp) → review+
http://hg.mozilla.org/mozilla-central/rev/03df7b14c2f2
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b4
Litmus test:
https://litmus.mozilla.org/show_test.cgi?id=12610
Flags: in-litmus+
Adding relnote so this gets picked up for the B3 release notes.
Keywords: relnote
Verified with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b4pre) Gecko/20100810 Minefield/4.0b4pre
Status: RESOLVED → VERIFIED
Reopening because I'm still seeing this on OS X. I don't see if during a full session restore, but when I re-open a closed window I see it. Specifically closing an window with 1 app tab & 1 normal tab, though it probably happens with any number. screen shot: http://grab.by/789W
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Bug 601228 has steps to reproduce this bug on Mac.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: