Closed Bug 618770 Opened 10 years ago Closed 9 years ago

Titlebar gradient breaks off abruptly at the toolbar in windows without tab bar when tabs are set on top

Categories

(Firefox :: Theme, defect)

All
macOS
defect
Not set
trivial

Tracking

()

RESOLVED FIXED
Firefox 12

People

(Reporter: bram, Assigned: dao)

References

Details

(Keywords: polish)

Attachments

(3 files, 2 obsolete files)

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
Version: unspecified → Trunk
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: polish
Duplicate of this bug: 620105
Summary: Titlebar gradient breaks off abruptly at the toolbar when tabs is set on top → Titlebar gradient breaks off abruptly at the toolbar in windows without tab bar when tabs are set on top
Duplicate of this bug: 629382
I only see this effect in toolbar-less pop-up windows.
4.0b11pre(2011-01-31)
Mac OS 10.6.6
(In reply to comment #5)
Forgot to add, that this is also happening only with the 'Tabs on top' option enabled.
Duplicate of this bug: 639435
Duplicate of this bug: 641573
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.
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?
Blocks: 643867
Duplicate of this bug: 645989
(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
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.
I'm still seeing it under both today's nightly and Aurora 7.0a2 on 10.7.
Actually yeah, disregard Comment 13, bad testing on my part.
I wonder if this bug depends on #<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=668195">668195</a>?
I meant to say Bug 668195. Sorry.
Attached patch v1 (obsolete) — Splinter Review
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Attachment #552342 - Flags: review?(dao)
Duplicate of this bug: 685033
Duplicate of this bug: 700049
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.
Attachment #552342 - Flags: review?(dao) → review-
Blocks: 621408
Blocks: 576439
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?
(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).
Attached patch patch v2 (obsolete) — Splinter Review
Assignee: mstange → dao
Attachment #552342 - Attachment is obsolete: true
Severity: major → trivial
Attachment #580788 - Flags: review?(gavin.sharp)
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
Blocks: 643130
Attached patch patch v2Splinter Review
typofix
Attachment #580788 - Attachment is obsolete: true
Attachment #580966 - Flags: review?(gavin.sharp)
Attachment #580788 - Flags: review?(gavin.sharp)
Attachment #580966 - Flags: review?(dolske)
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. :)
Attachment #580966 - Flags: review?(gavin.sharp)
Attachment #580966 - Flags: review?(dolske)
Attachment #580966 - Flags: review+
(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
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.
https://hg.mozilla.org/mozilla-central/rev/440b585a2896
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
There is a issue now. Filed bug 716334. Thanks.
Depends on: 716334
Depends on: 716692
Duplicate of this bug: 722826
Hi, there is still a bug. I filed bug 737158. Thanks.
Depends on: 749037
Depends on: 844651
You need to log in before you can comment on or make changes to this bug.