left tab title text shifts when a new tab is added

RESOLVED FIXED in Firefox 4.0b9

Status

()

Firefox
Theme
RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: Robert Sayre, Assigned: fryn)

Tracking

(Blocks: 1 bug, {polish})

Trunk
Firefox 4.0b9
All
Mac OS X
polish
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(1 attachment, 4 obsolete attachments)

(Reporter)

Description

8 years ago
STR:

1.) open Minefield
2.) first tab is titled "Minefield Start Page"
3.) add and close a second tab
4.) observe the first tab's title text shift as the close button is added removed
(Reporter)

Updated

8 years ago
status2.0: --- → ?
(Reporter)

Updated

8 years ago
blocking2.0: --- → ?

Updated

8 years ago
Component: Tabbed Browser → Theme
QA Contact: tabbed.browser → theme

Updated

8 years ago
Duplicate of this bug: 585465
This looks like a similar problem to bug 579323. Roc, agree?
Status: NEW → RESOLVED
blocking2.0: ? → ---
Last Resolved: 7 years ago
status2.0: ? → ---
Resolution: --- → DUPLICATE
Duplicate of bug: 579323
This is marked as a dupe of bug 579323, but now that bug 579323 landed, I am still observing this behaviour in 20100831.
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk

Updated

7 years ago
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
blocking2.0: --- → final+
The tab label is centered on OS X, so when the tab's close button is removed, the label's available width increases and the center shifts to the right. This isn't a new problem as far as I can see.
OS: All → Mac OS X
I agree with Dao, I don't think this is a regression, or bad enough to block. Roc, please feel free to re-nom if you disagree.
blocking2.0: final+ → -
(Reporter)

Comment 7

7 years ago
(In reply to comment #6)
> please feel free to re-nom if you disagree.

I do.
blocking2.0: - → ?
(Reporter)

Comment 8

7 years ago
Here is a YouTube video showing the behavior at 50% speed:

http://www.youtube.com/watch?v=iA2rsmLprYg

The mistake is to remove the space needed for the tab close button at all. When the user opens a new tab, the browser distractingly realigns the text in the old tab. The special case of one tab open is not that interesting to optimize for, because the full title is always shown in the title bar in that case.

This behavior also causes related bugs, since the "New Tab" text is realigned just as the second tab reaches full width.

All tabs should appear exactly the same. These non-uniform alignment shifts give the software a low quality feel.
(Reporter)

Comment 9

7 years ago
It's been three weeks since I renominated this bug.
It's been four weeks since I've been to the gym.

Rob's right, this is a visible twitch to the UI which results in an overall lesser feel. Over to Faaborg to determine where it falls in the pantheon of polish bugs, and he can renominate for blocking at that time.

Best solution, as Rob says (and Safari does) is to just continually reserve the space and save us the layout hassle. I don't think this blocks release, but agree that it's a high leverage low cost polish item that should be tracked in Alex's list.
Keywords: polish
blocking2.0: ? → -
(Assignee)

Comment 11

7 years ago
I'm pretty certain that this is fixable with just fancy CSS selector magic. I'll give it a shot.
Assignee: nobody → fryn
Status: REOPENED → ASSIGNED
(Assignee)

Comment 12

7 years ago
Created attachment 499232 [details] [diff] [review]
patch

Simple patch.

It reserves the space on OS X but not on other platforms.
It also fixes (without any additional code) the same issue when browser.tabs.closeButtons is a value other than the default 1.
Attachment #499232 - Flags: review?(dao)
Comment on attachment 499232 [details] [diff] [review]
patch

Rather than adding "noclosemac", I think you should handle this completely in pinstripe's browser.css. tabbrowser.css and tabbrowser.xml don't need to know about this. But: I'm not convinced that this is even the solution we want, as it reduces the space available for tab titles when the tabs are at their minimum size.
Attachment #499232 - Flags: review?(dao) → review-
Bug 349108 would solve this too.
(Assignee)

Comment 15

7 years ago
Comment on attachment 499232 [details] [diff] [review]
patch

(In reply to comment #13)

AFAIK, browser.css does not have access to the anonymous nodes. Even if it does, there is no way to know when a tab's nextSibling is being closed in CSS, so tab:only-of-type or tab:only-child is insufficient to fix this.

My patch only reduces the space available for the tab title when there is only 1 tab. Please read the patch. I should have clarified that the space is only reserved when only one tab is open.
Attachment #499232 - Flags: review- → review?
(Assignee)

Updated

7 years ago
Attachment #499232 - Flags: review? → review?(dao)
(Assignee)

Comment 16

7 years ago
(In reply to comment #14)
> Bug 349108 would solve this too.

It's not clear that we still want that UI. I talked to Limi about that, and we came to the conclusion that close buttons on the right side make more sense.
Comment on attachment 499232 [details] [diff] [review]
patch

(In reply to comment #15)
> AFAIK, browser.css does not have access to the anonymous nodes.

It does.

> there is no way to know when a tab's nextSibling is being closed in CSS,
> so tab:only-of-type or tab:only-child is insufficient to fix this.

Simple solution is to just not call adjustTabstrip in _beginRemoveTab as your patch does.
Attachment #499232 - Flags: review?(dao) → review-
(Assignee)

Comment 18

7 years ago
Created attachment 499253 [details] [diff] [review]
simpler patch

(In reply to comment #17)

When you have two tabs, and one closes, selection shifts immediately to the other tab, so the close button immediately appears on that tab. adjustTabStrip should called immediately in order to make the close button disappear, but if you find that brief state to be acceptable, this simpler patch will do.

It will reserve the space when browser.tabs.closeButtons is 2 or 3 though, but I figure that we don't need to bother with those obscure pref values.
Attachment #499232 - Attachment is obsolete: true
Attachment #499253 - Flags: review?(dao)
(In reply to comment #18)
> When you have two tabs, and one closes, selection shifts immediately to the
> other tab, so the close button immediately appears on that tab.

It doesn't appear, it was already there in the case of two tabs, so what happens is that it disappears when the second tab has been closed.

> adjustTabStrip
> should called immediately in order to make the close button disappear, but if
> you find that brief state to be acceptable, this simpler patch will do.

It's only tangentially related to this bug, anyway.

> It will reserve the space when browser.tabs.closeButtons is 2 or 3 though, but
> I figure that we don't need to bother with those obscure pref values.

So why don't you use :only-of-type/:only-child? Alternative solution would be to not overload "noclose" the way it's currently overloaded in order to allow pinstripe to differentiate.
(Assignee)

Comment 20

7 years ago
(In reply to comment #19)
> So why don't you use :only-of-type/:only-child?

If I use :only-of-type/:only-child, when there is one tab and another is opened, the tab text will shift to the right until adjustTabStrip is called in _handleNewTab to change closebuttons to "alltabs". If you think un-overloading "noclose" is worth it, let it be known, and I'll write a patch with that. Otherwise, this should do.
browser.tabs.closeButtons=3 used to be the default, so a few people are probably attached to that. Should be simple enough, too.
(Assignee)

Comment 22

7 years ago
Created attachment 499256 [details] [diff] [review]
patch v3

It turns out that we no longer use "closeatend", so I removed that from tabbrowser.css.
Attachment #499253 - Attachment is obsolete: true
Attachment #499256 - Flags: review?(dao)
Attachment #499253 - Flags: review?(dao)
(Assignee)

Comment 23

7 years ago
Created attachment 499258 [details] [diff] [review]
patch v4

fixed a selector typo.
Attachment #499256 - Attachment is obsolete: true
Attachment #499258 - Flags: review?(dao)
Attachment #499256 - Flags: review?(dao)
Comment on attachment 499258 [details] [diff] [review]
patch v4

It's not really clear what "hidden" means as opposed to "noclose". How about "never" for 2 and 3?
(Assignee)

Comment 25

7 years ago
(In reply to comment #24)
> Comment on attachment 499258 [details] [diff] [review]
> patch v4
> 
> It's not really clear what "hidden" means as opposed to "noclose". How about
> "never" for 2 and 3?

That works. We could also removeAttribute("closebuttons")
Which?
[no attribute] vs. "noclose" or "hidden" also seems subtle.
(Assignee)

Comment 27

7 years ago
Created attachment 499261 [details] [diff] [review]
patch v5
Attachment #499258 - Attachment is obsolete: true
Attachment #499261 - Flags: review?(dao)
Attachment #499258 - Flags: review?(dao)

Updated

7 years ago
Attachment #499261 - Flags: review?(dao) → review+
(Assignee)

Updated

7 years ago
Attachment #499261 - Flags: approval2.0?
Attachment #499261 - Flags: approval2.0? → approval2.0+
Blocks: 467530
(Assignee)

Comment 28

7 years ago
Pushed yesterday. Forgot to list changeset.

https://hg.mozilla.org/mozilla-central/rev/11362bbb1bfa
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b9
(Assignee)

Updated

7 years ago
See Also: → bug 624595
You need to log in before you can comment on or make changes to this bug.