Bogdan Maris, Desktop QA Reporter
	Description • 10 years ago

Please feel free to mark this bug as secure/private if you think is necessary.

STR:
1. Open Firefox Developer Edition.
2. Open new tabs until the tabbar becomes overpopulated and navigation arrow buttons appear.
3. Focus the last tab opened.
4. Start closing tabs.

Expected result: Navigation right arrow button is inactive after closing the very last tab from right.

Actual result: After a few tabs closed the navigation right arrow button becomes active and does nothing if it`s clicked.

Mac OS only: Also here I saw that between the first tab opened and minimize/close/maximize buttons in Mac OS X there is much unused space. Is this intended?

Notes:
1. This issue reproduces on all platforms.
2. Screencast attached showing the issue.

	Matthew N. [:MattN]
	Comment 1 • 10 years ago

I reported this in https://reviewboard.mozilla.org/r/131/#fcomment11 too

	Brian Grinstead [:bgrins] Assignee
	Comment 2 • 10 years ago

I don't know for sure, but I think the patch from Bug 1093820 *may* fix this.  Can someone test out with it applied and let me know?

	Jordan Santell [:jsantell] [@jsantell]
	Comment 3 • 10 years ago

Checking it out now, Brian

	Jordan Santell [:jsantell] [@jsantell]
	Comment 4 • 10 years ago

Oh my it does. *whew* leaving this open for verification once bug 1093820 lands.

	Brian Grinstead [:bgrins] Assignee
	Comment 5 • 10 years ago

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #0)
> Mac OS only: Also here I saw that between the first tab opened and
> minimize/close/maximize buttons in Mac OS X there is much unused space. Is
> this intended?

Yes, that's to give some extra dragging space since there isn't any above the tab bar.  It's 50px extra space, as per the designs.

	Brian Grinstead [:bgrins] Assignee
	Comment 6 • 10 years ago

This is a simpler patch than the one on 1093820.  It should fix this problem.

	Matthew N. [:MattN]
	Comment 7 • 10 years ago

Comment on attachment 8518484 [details] [diff] [review]
tabCurveHalfWidth.patch

Review of attachment 8518484 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/themes/shared/devedition.inc.css
@@ +74,5 @@
> +/* Override @tabCurveHalfWidth@.  XXX: Switch to a CSS variable once the perf is sorted out - bug 1088771 */
> +.tab-background-middle {
> +  border-left-width: 0;
> +  border-right-width: 0;
> +  margin: 0;

In some ways I think you should just change the left/right margin since that's what is using tabCurveHalfWidth. That would allow devedition to inherit future changes although it's hard to predict if that would be wanted or not.

@@ +78,5 @@
> +  margin: 0;
> +}
> +
> +.tab-background,
> +.tabs-newtab-button {

I kinda wonder about including a comment mentioning @tabCurveHalfWidth@ on top of this ruleset and the one below too. Otherwise, I think we should have a start and end comment.

@@ +87,3 @@
>  .tabbrowser-arrowscrollbox > .arrowscrollbox-scrollbox {
>    padding-left: 0;
>    padding-right: 0;

Can you also change these to -moz-padding-* to match tabs.inc.css?

	Matthew N. [:MattN]
	Comment 8 • 10 years ago

Also, what about tabCurveWidth?

	Brian Grinstead [:bgrins] Assignee
	Comment 9 • 10 years ago

(In reply to Matthew N. [:MattN] (focused on Loop) from comment #7)
> Comment on attachment 8518484 [details] [diff] [review]
> tabCurveHalfWidth.patch
> 
> Review of attachment 8518484 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/themes/shared/devedition.inc.css
> @@ +74,5 @@
> > +/* Override @tabCurveHalfWidth@.  XXX: Switch to a CSS variable once the perf is sorted out - bug 1088771 */
> > +.tab-background-middle {
> > +  border-left-width: 0;
> > +  border-right-width: 0;
> > +  margin: 0;
> 
> In some ways I think you should just change the left/right margin since
> that's what is using tabCurveHalfWidth. That would allow devedition to
> inherit future changes although it's hard to predict if that would be wanted
> or not.
> 

I'd prefer for now to stick with existing props since it feels safer.  Next step I hope is to convert it into a CSS variable - I think this would protect against the types of changes you are talking about?

> @@ +78,5 @@
> > +  margin: 0;
> > +}
> > +
> > +.tab-background,
> > +.tabs-newtab-button {
> 
> I kinda wonder about including a comment mentioning @tabCurveHalfWidth@ on
> top of this ruleset and the one below too. Otherwise, I think we should have
> a start and end comment.
> 

Added start/end comment and updated to include tabCurveWidth

> @@ +87,3 @@
> >  .tabbrowser-arrowscrollbox > .arrowscrollbox-scrollbox {
> >    padding-left: 0;
> >    padding-right: 0;
> 
> Can you also change these to -moz-padding-* to match tabs.inc.css?

Done

(In reply to Matthew N. [:MattN] (focused on Loop) from comment #8)
> Also, what about tabCurveWidth?

Done

	Brian Grinstead [:bgrins] Assignee
	Comment 10 • 10 years ago

https://hg.mozilla.org/integration/fx-team/rev/1000e0bc7686

	Brian Grinstead [:bgrins] Assignee
	Comment 11 • 10 years ago

Bogdan, can you please confirm if this if fixed on the latest gum build?

	Bogdan Maris, Desktop QA Reporter
	Comment 12 • 10 years ago

Tested using https://hg.mozilla.org/projects/gum/rev/f426e446b9aa build, was not able to reproduce anymore. 

I also saw a possible new issue: If I overpopulate the tabbar with tabs until navigation buttons appear, start closing tabs using the mouse by clicking on 'x'. After the navigation buttons disappear, there can be seen a area on the right of '+' button that is colored in default theme. Though it disappears if the mouse pointer is moved away from tabbar.

Image showing the issue: https://db.tt/ATCfcQSt
(sorry for the external link but I did not think is necessary to add the image to this bug)

Is this a known issue or should I log a new bug on this?

	Carsten Book [:Tomcat]
	Comment 13 • 10 years ago

https://hg.mozilla.org/mozilla-central/rev/1000e0bc7686

	Brian Grinstead [:bgrins] Assignee
	Comment 15 • 10 years ago

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #12)
> Tested using https://hg.mozilla.org/projects/gum/rev/f426e446b9aa build, was
> not able to reproduce anymore. 
> 
> I also saw a possible new issue: If I overpopulate the tabbar with tabs
> until navigation buttons appear, start closing tabs using the mouse by
> clicking on 'x'. After the navigation buttons disappear, there can be seen a
> area on the right of '+' button that is colored in default theme. Though it
> disappears if the mouse pointer is moved away from tabbar.
> 
> Image showing the issue: https://db.tt/ATCfcQSt
> (sorry for the external link but I did not think is necessary to add the
> image to this bug)
> 
> Is this a known issue or should I log a new bug on this?

Please log another bug for this.

	Ryan VanderMeulen [:RyanVM]
	Comment 16 • 10 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/c1515955999b

	Maurya Talisetti
	Comment 17 • 10 years ago

Verified in:
Nightly 36.0a1 (2014-11-26)  : Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0
Dev Edition 35.0a2 (2014-11-26):Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

Couldn't reproduce the bug on the broken build since I'm not sure which nightly it was.

	Maurya Talisetti
	Comment 18 • 10 years ago

^ [bugday-20141126]

	Bogdan Maris, Desktop QA Reporter
	Comment 19 • 10 years ago

Thanks Maurya for the verification.
You can use this build to try and reproduce the issue. I see you use Windows so here it is: 
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/gum-win32/1415275327/firefox-35.0a2.en-US.win32.zip

Next time if you verify a fix and have the credentials to modify the tracking flags (eg here: status-firefox35: fixed), the right way to do it is to change 'fixed' to 'verified' not delete the flag :)

I also verified the fix for on all platforms and can confirm that the issue is fixed.