Last Comment Bug 618770 - Titlebar gradient breaks off abruptly at the toolbar in windows without tab bar when tabs are set on top
: Titlebar gradient breaks off abruptly at the toolbar in windows without tab b...
Status: RESOLVED FIXED
: polish
Product: Firefox
Classification: Client Software
Component: Theme (show other bugs)
: Trunk
: All Mac OS X
: -- trivial with 4 votes (vote)
: Firefox 12
Assigned To: Dão Gottwald [:dao]
:
Mentors:
: 620105 629382 639435 641573 645989 685033 700049 722826 (view as bug list)
Depends on: 716334 716692 749037 844651
Blocks: 576439 621408 643130 643867
  Show dependency treegraph
 
Reported: 2010-12-12 22:16 PST by Bram Pitoyo [:bram]
Modified: 2013-11-12 00:57 PST (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Broken titlebar gradient when tabs is set on top (26.53 KB, image/png)
2010-12-12 22:22 PST, Bram Pitoyo [:bram]
no flags Details
Gradient broken on a toolbarless window (10.48 KB, image/png)
2011-01-31 13:23 PST, u220127
no flags Details
v1 (5.65 KB, patch)
2011-08-11 05:32 PDT, Markus Stange [:mstange]
dao+bmo: review-
Details | Diff | Splinter Review
patch v2 (9.48 KB, patch)
2011-12-11 14:10 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v2 (9.48 KB, patch)
2011-12-12 10:47 PST, Dão Gottwald [:dao]
dolske: review+
Details | Diff | Splinter Review

Description Bram Pitoyo [:bram] 2010-12-12 22:16:19 PST
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.16 Safari/534.13
Build Identifier: Trunk

The gradient in the titlebar breaks off abruptly at the point at which it touches the toolbar when: 1) tabs is set on top, and 2) there is no tab open.

Educated guess/possible problem: the chrome stretches the gradient value down to fit an unexpanded space, creating a color that does not blend with its bottom neighbor

The same problem is also seen in the inactive window, though less pronounced.

Reproducible: Always

Steps to Reproduce:
1. Set Minefield to use Tabs on Top
2. Close all open tabs, leaving one open
Actual Results:  
Titlebar gradient eliminate abruptly at the toolbar.

Expected Results:  
Gradient should flow smoothly
Comment 1 Bram Pitoyo [:bram] 2010-12-12 22:22:40 PST
Created attachment 497220 [details]
Broken titlebar gradient when tabs is set on top
Comment 2 Markus Stange [:mstange] 2010-12-13 02:22:44 PST
Dão, is it possible for the #nav-bar to tell whether the tabs toolbar is visible or not? If not, should we add an attribute to the toolbox?
Comment 3 Markus Stange [:mstange] 2010-12-18 07:35:10 PST
*** Bug 620105 has been marked as a duplicate of this bug. ***
Comment 4 Markus Stange [:mstange] 2011-01-28 01:13:34 PST
*** Bug 629382 has been marked as a duplicate of this bug. ***
Comment 5 u220127 2011-01-31 13:23:22 PST
Created attachment 508517 [details]
Gradient broken on a toolbarless window

I only see this effect in toolbar-less pop-up windows.
4.0b11pre(2011-01-31)
Mac OS 10.6.6
Comment 6 u220127 2011-01-31 13:24:58 PST
(In reply to comment #5)
Forgot to add, that this is also happening only with the 'Tabs on top' option enabled.
Comment 7 Markus Stange [:mstange] 2011-03-07 08:22:10 PST
*** Bug 639435 has been marked as a duplicate of this bug. ***
Comment 8 Markus Stange [:mstange] 2011-03-14 12:57:21 PDT
*** Bug 641573 has been marked as a duplicate of this bug. ***
Comment 9 Kevin Cannon 2011-03-22 08:16:47 PDT
Just to confirm, this is still a problem in Firefox 4 RC2.

It happens whenever the tab bar is not visible.

This can happen in many situations such as popup windows, and also simply having no tabs open and the 'always show tab bar' setting unchecked.
Comment 10 Bram Pitoyo [:bram] 2011-03-22 08:39:25 PDT
Firefox 4 works around this bug by having this "always show tab bar" setting turned on by default. Minefield doesn’t have this option, though.

Maybe we could implement this feature on Minefield so it’s easier to perform testing on this and other gradient-related bugs?
Comment 11 Markus Stange [:mstange] 2011-03-29 03:44:41 PDT
*** Bug 645989 has been marked as a duplicate of this bug. ***
Comment 12 Bram Pitoyo [:bram] 2011-05-12 01:39:24 PDT
(In reply to comment #2)
> Dão, is it possible for the #nav-bar to tell whether the tabs toolbar is
> visible or not? If not, should we add an attribute to the toolbox?

I wonder if this bug is related to Bug 537273 - Make -moz-appearance: toolbar also draw a gradient if the toolbar is at the top of a drawintitlebar="true" window

https://bugzilla.mozilla.org/show_bug.cgi?id=537273
Comment 13 Anthony Ricaud (:rik) 2011-08-11 00:36:05 PDT
I was gonnna comment that this is fixed with the new look on latest Nightly.

But actually, I'm not seeing this under Aurora on 10.7 either. So it seems to be 10.5/10.6 only now.
Comment 14 Loic Nageleisen 2011-08-11 00:57:29 PDT
I'm still seeing it under both today's nightly and Aurora 7.0a2 on 10.7.
Comment 15 Anthony Ricaud (:rik) 2011-08-11 01:11:25 PDT
Actually yeah, disregard Comment 13, bad testing on my part.
Comment 16 Bram Pitoyo [:bram] 2011-08-11 03:16:47 PDT
I wonder if this bug depends on #<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=668195">668195</a>?
Comment 17 Bram Pitoyo [:bram] 2011-08-11 03:17:50 PDT
I meant to say Bug 668195. Sorry.
Comment 18 Markus Stange [:mstange] 2011-08-11 05:32:04 PDT
Created attachment 552342 [details] [diff] [review]
v1
Comment 19 Markus Stange [:mstange] 2011-09-06 22:25:40 PDT
*** Bug 685033 has been marked as a duplicate of this bug. ***
Comment 20 Dão Gottwald [:dao] 2011-11-05 11:20:27 PDT
*** Bug 700049 has been marked as a duplicate of this bug. ***
Comment 21 Dão Gottwald [:dao] 2011-11-05 11:26:39 PDT
Comment on attachment 552342 [details] [diff] [review]
v1

I don't like the addition of the visibletabsontop attribute. Can we just not set the tabsontop attribute in that case? We'll need to remove persist="tabsontop" in browser.xul for that and do the persisting in the script.
Comment 22 Markus Stange [:mstange] 2011-11-13 05:54:40 PST
I've tried that idea and it didn't really work out. What should happen if somebody toggles the tabsontop checkbox while tabs are hidden? What values should the enabled getter return during that time? If the getter doesn't read the current state from tabsontop attribute, how should it know about the persisted value?
Comment 23 Dão Gottwald [:dao] 2011-11-13 06:10:03 PST
(In reply to Markus Stange from comment #22)
> I've tried that idea and it didn't really work out. What should happen if
> somebody toggles the tabsontop checkbox while tabs are hidden?

The checkbox should probably be disabled or hidden; it might make sense to let the toggle function do nothing in that case, too.

> What values should the enabled getter return during that time?

Based on the two external places that read TabsOnTop.enabled, I'd say it should reflect the actual attribute state (not what's persisted).
Comment 24 Dão Gottwald [:dao] 2011-12-11 14:10:25 PST
Created attachment 580788 [details] [diff] [review]
patch v2
Comment 25 Jared Wein [:jaws] (please needinfo? me) 2011-12-11 14:28:03 PST
Comment on attachment 580788 [details] [diff] [review]
patch v2

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

::: browser/components/nsBrowserGlue.js
@@ +1223,5 @@
>      }
>  
> +    if (currentUIVersion < 6) {
> +      // convert tabsontop attribute to pref
> +      let tooloxResource = this._rdf.GetResource(BROWSER_DOCURL + "navigator-toolbox");

nit: This should probably be toolboxResource
Comment 26 Dão Gottwald [:dao] 2011-12-12 10:47:51 PST
Created attachment 580966 [details] [diff] [review]
patch v2

typofix
Comment 27 Justin Dolske [:Dolske] 2012-01-05 18:29:07 PST
Comment on attachment 580966 [details] [diff] [review]
patch v2

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

I didn't review this in depth, but looks fine. Flag again if you want a nitpicky review. :)
Comment 29 Dão Gottwald [:dao] 2012-01-06 05:14:56 PST
(In reply to Dão Gottwald [:dao] from comment #28)
> http://hg.mozilla.org/integration/mozilla-inbound/rev/5fbe5ee99a27

backed out because browser_bug321000.js was failing
Comment 30 Ed Morley [:emorley] 2012-01-06 15:44:56 PST
The fix to the ally test has now been merged to m-c (https://hg.mozilla.org/mozilla-central/rev/e1b77400dc94), leaving open for the relanding of the main patch.
Comment 32 Ed Morley [:emorley] 2012-01-07 19:32:03 PST
https://hg.mozilla.org/mozilla-central/rev/440b585a2896
Comment 33 Mehmet 2012-01-08 01:35:36 PST
There is a issue now. Filed bug 716334. Thanks.
Comment 34 Markus Stange [:mstange] 2012-02-01 02:21:37 PST
*** Bug 722826 has been marked as a duplicate of this bug. ***
Comment 35 Mehmet 2012-03-19 13:19:48 PDT
Hi, there is still a bug. I filed bug 737158. Thanks.

Note You need to log in before you can comment on or make changes to this bug.