Closed
Bug 655797
Opened 13 years ago
Closed 13 years ago
Recalculate whether to show close buttons after resizing tabs
Categories
(Firefox :: Tabbed Browser, defect)
Firefox
Tabbed Browser
Tracking
()
VERIFIED
FIXED
Firefox 6
People
(Reporter: tabutils+bugzilla, Assigned: fryn)
References
Details
Attachments
(1 file)
1.25 KB,
patch
|
dao
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Tab close buttons don't show after repeatedly closing some tabs and moving mouse out of the tab bar even if tabClipWidth is exceeded. Reproducible: Always Steps to Reproduce: 1. Open enough tabs to ensure tab close buttons are hidden 2. Close some tabs from the middle 3. Move mouse out of the tab bar Actual Results: Tab close buttons don't show Expected Results: Tab close button should show if tab width exceeds tabClipWidth
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → fryn
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Call adjustTabstrip() in _unlockTabSizing → Recalculate whether to show close buttons after resizing tabs
Assignee | ||
Comment 1•13 years ago
|
||
Attachment #531253 -
Flags: review?(dao)
Updated•13 years ago
|
Attachment #531253 -
Flags: review?(dao) → review+
Comment on attachment 531253 [details] [diff] [review] patch Review of attachment 531253 [details] [diff] [review]: ----------------------------------------------------------------- So you're assuming the tab animation is always on. What if the tab animation is off?
Assignee | ||
Comment 3•13 years ago
|
||
(In reply to comment #2) > So you're assuming the tab animation is always on. What if the tab animation > is off? That'll be handled in bug 649671.
Keywords: checkin-needed
Comment 4•13 years ago
|
||
http://hg.mozilla.org/projects/cedar/rev/dbeeaffd5bea
Keywords: checkin-needed
Whiteboard: fixed-in-cedar
As the function name is _handleNewTab, I still think there's some improperness here.
Assignee | ||
Comment 6•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/dbeeaffd5bea
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 6
Updated•13 years ago
|
Whiteboard: fixed-in-cedar
Comment 7•13 years ago
|
||
(In reply to comment #5) > As the function name is _handleNewTab, I still think there's some > improperness here. Yeah, this is gross. We should rename the function, and the very least.
Assignee | ||
Comment 8•13 years ago
|
||
(In reply to comment #7) > (In reply to comment #5) > > As the function name is _handleNewTab, I still think there's some > > improperness here. > > Yeah, this is gross. We should rename the function, and the very least. I don't think renaming the function to sth like _handleResizeTab is a good idea, since that function is called for new tabs that don't use the opening animation too. I'll fix this in the just-filed bug 657463.
Comment 9•13 years ago
|
||
Can we get an automated test for fixes like that? A lot of code goes into the tabbrowser component but mostly we don't have tests. :/
Flags: in-testsuite?
Assignee | ||
Comment 10•13 years ago
|
||
(In reply to comment #9) > Can we get an automated test for fixes like that? A lot of code goes into > the tabbrowser component but mostly we don't have tests. :/ I'd make a test for this in the patch for bug 657463 or bug 649671.
Comment 11•13 years ago
|
||
If i delete some tabs from the middle, the "x" button still doesn't show. It shows only when a few tabs remains. This is the intended behavior?
Comment 12•13 years ago
|
||
Mozilla/5.0 (X11; Linux i686; rv:7.0a1) Gecko/20110630 Firefox/7.0a1 Verified issue on Ubuntu 11.04, Mac OS X 10.6, WinXP, Win 7 using steps from Comment 1. Problem no longer reproducible -> setting status to Verified Fixed.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•