As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact bugzilla-admin@mozilla.org
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]
:
: 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 User image 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 User image 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 User image 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 User image Markus Stange [:mstange] 2010-12-18 07:35:10 PST
*** Bug 620105 has been marked as a duplicate of this bug. ***
Comment 4 User image Markus Stange [:mstange] 2011-01-28 01:13:34 PST
*** Bug 629382 has been marked as a duplicate of this bug. ***
Comment 5 User image 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 User image 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 User image Markus Stange [:mstange] 2011-03-07 08:22:10 PST
*** Bug 639435 has been marked as a duplicate of this bug. ***
Comment 8 User image Markus Stange [:mstange] 2011-03-14 12:57:21 PDT
*** Bug 641573 has been marked as a duplicate of this bug. ***
Comment 9 User image 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 User image 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 User image Markus Stange [:mstange] 2011-03-29 03:44:41 PDT
*** Bug 645989 has been marked as a duplicate of this bug. ***
Comment 12 User image 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 User image 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 User image 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 User image Anthony Ricaud (:rik) 2011-08-11 01:11:25 PDT
Actually yeah, disregard Comment 13, bad testing on my part.
Comment 16 User image 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 User image Bram Pitoyo [:bram] 2011-08-11 03:17:50 PDT
I meant to say Bug 668195. Sorry.
Comment 18 User image Markus Stange [:mstange] 2011-08-11 05:32:04 PDT
Created attachment 552342 [details] [diff] [review]
v1
Comment 19 User image Markus Stange [:mstange] 2011-09-06 22:25:40 PDT
*** Bug 685033 has been marked as a duplicate of this bug. ***
Comment 20 User image Dão Gottwald [:dao] 2011-11-05 11:20:27 PDT
*** Bug 700049 has been marked as a duplicate of this bug. ***
Comment 21 User image 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 User image 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 User image 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 User image Dão Gottwald [:dao] 2011-12-11 14:10:25 PST
Created attachment 580788 [details] [diff] [review]
patch v2
Comment 25 User image 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 User image Dão Gottwald [:dao] 2011-12-12 10:47:51 PST
Created attachment 580966 [details] [diff] [review]
patch v2

typofix
Comment 27 User image 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 User image 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 User image 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 User image Ed Morley [:emorley] 2012-01-07 19:32:03 PST
https://hg.mozilla.org/mozilla-central/rev/440b585a2896
Comment 33 User image Mehmet 2012-01-08 01:35:36 PST
There is a issue now. Filed bug 716334. Thanks.
Comment 34 User image Markus Stange [:mstange] 2012-02-01 02:21:37 PST
*** Bug 722826 has been marked as a duplicate of this bug. ***
Comment 35 User image 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.