Closed
Bug 591930
Opened 14 years ago
Closed 14 years ago
Persona background is drawn too high in titlebar
Categories
(Firefox :: Theme, defect)
Tracking
()
RESOLVED
FIXED
Firefox 4.0b7
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: jimm, Assigned: Felipe)
References
Details
Attachments
(5 files, 2 obsolete files)
(deleted),
image/png
|
Details | |
(deleted),
image/jpeg
|
shorlander
:
ui-review+
|
Details |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
dao
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
dao
:
review+
|
Details | Diff | Splinter Review |
We need to shift the painting of the persona background-image down one or two pixels, it currently covers the window border. We have moz extensions that may be able to help:
https://developer.mozilla.org/en/css/background-image
Otherwise we might need to create a new extension.
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Updated•14 years ago
|
blocking2.0: ? → betaN+
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → felipc
Status: NEW → ASSIGNED
Assignee | ||
Comment 1•14 years ago
|
||
Here are 5 different implementations to adjust the window border and button position, based on the mockups here and the original bug 513170, and also an extra one as suggested to show the window glass resizer borders.
Shorlander, can you take a look at these and tell what you think is the most correct one?
Attachment #471221 -
Flags: ui-review?(shorlander)
Reporter | ||
Comment 2•14 years ago
|
||
My personal take is a or e, leaning toward e until we have the rest of the frame skinned.
Comment 4•14 years ago
|
||
I’m for A as well. Maybe the transparency might be a bit less then 50% but definitely not solid white as in C.
Assignee | ||
Comment 5•14 years ago
|
||
CC'ing faaborg for feedback on the screenshots
Comment 6•14 years ago
|
||
>CC'ing faaborg for feedback on the screenshots
stephen should make the call on this
Comment 7•14 years ago
|
||
Comment on attachment 471221 [details]
5 different implementations
A is correct. Actually 0.6 alpha is probably closer to what the system border does.
Attachment #471221 -
Flags: ui-review?(shorlander) → ui-review+
Assignee | ||
Comment 8•14 years ago
|
||
Implemented style A with 0.6 alpha on the inner border.
Since the attempts of shifting the bg-color and -image wouldn't work in practice, the solution is to draw the top borders of the window ourselves.
I already wrote and tested this one on top of patch from bug 593950
Attachment #472845 -
Flags: review?(dao)
Assignee | ||
Comment 9•14 years ago
|
||
FTR, I updated the patch comment to say:
- /* Redraw borders */
+ /* Artificially draw window borders that are covered by lwtheme */
Comment 10•14 years ago
|
||
Comment on attachment 472845 [details] [diff] [review]
Patch v1
>+ #main-window[chromemargin^="0,"] {
>+ border-top: 1px solid transparent;
>+ }
>+
>+ #main-window[chromemargin^="0,"] > #titlebar > #titlebar-content {
>+ border-top: 1px solid transparent;
>+ }
>+
>+ #main-window[chromemargin^="0,"] > #titlebar > #titlebar-content > #appmenu-button-container {
>+ margin-top: -1px !important;
>+ }
>+
>+ #main-window[chromemargin^="0,"] > #titlebar {
>+ margin-bottom: -1px;
>+ }
Why is all this applied if there's no lwtheme?
>+ #main-window[sizemode="normal"]:-moz-lwtheme > #titlebar > #titlebar-content {
>+ border-top-color: rgba(255, 255, 255, 0.6);
>+ }
move :-moz-lwtheme to #titlebar-content
Comment 11•14 years ago
|
||
Is bug 547805 considered in this work, or does it not affect the positioning of the background?
Assignee | ||
Comment 12•14 years ago
|
||
(In reply to comment #10)
> Comment on attachment 472845 [details] [diff] [review]
> Patch v1
>
> >+ #main-window[chromemargin^="0,"] {
> >+ border-top: 1px solid transparent;
> >+ }
> >+
> >+ #main-window[chromemargin^="0,"] > #titlebar > #titlebar-content {
> >+ border-top: 1px solid transparent;
> >+ }
> >+
> >+ #main-window[chromemargin^="0,"] > #titlebar > #titlebar-content > #appmenu-button-container {
> >+ margin-top: -1px !important;
> >+ }
> >+
> >+ #main-window[chromemargin^="0,"] > #titlebar {
> >+ margin-bottom: -1px;
> >+ }
>
> Why is all this applied if there's no lwtheme?
Because the positioning of the elements is affected by the borders added, so I preferred to have a single final layout and make the borders transparent/not transparent, rather than having to shift things up/down when the lwtheme is applied.
>
> >+ #main-window[sizemode="normal"]:-moz-lwtheme > #titlebar > #titlebar-content {
> >+ border-top-color: rgba(255, 255, 255, 0.6);
> >+ }
>
> move :-moz-lwtheme to #titlebar-content
Ok
Comment 13•14 years ago
|
||
Is the drawing error in the attachment related to this bug, or should I file a new bug?
Comment 14•14 years ago
|
||
Comment on attachment 472845 [details] [diff] [review]
Patch v1
In order to prevent accidental height increases or alignment changes (now or in the future), please apply your code only in the :-moz-lwtheme case.
Attachment #472845 -
Flags: review?(dao) → review-
Assignee | ||
Comment 15•14 years ago
|
||
New patch, with a much better solution now. Before, to draw the two-colors border I was using the border of both the window and the titlebar-content. This lead to some tricky positioning issues, but now I'm using the -moz-border-top-colors to draw both of them to the titlebar-content, which simplifies things as it doesn't deal with the root element anymore.
(In reply to comment #14)
> In order to prevent accidental height increases or alignment changes (now or in
> the future), please apply your code only in the :-moz-lwtheme case.
I've applied everything to the :-moz-lwtheme case now. FWIW the original idea to apply the borders on both cases was exactly to prevent accidental changes (avoiding a different layout for lwtheme), but I'm fine with it either way.
(In reply to comment #13)
> Created attachment 476512 [details]
> Drawing in the XP title bar
>
> Is the drawing error in the attachment related to this bug, or should I file a
> new bug?
I took a look and tried to do it together here, but turns out that'll need some trickier changes so it's probably better done in a separate bug.
Attachment #472845 -
Attachment is obsolete: true
Attachment #479622 -
Flags: review?(dao)
Comment 16•14 years ago
|
||
(In reply to comment #15)
> (In reply to comment #14)
> > In order to prevent accidental height increases or alignment changes (now or in
> > the future), please apply your code only in the :-moz-lwtheme case.
>
> I've applied everything to the :-moz-lwtheme case now. FWIW the original idea
> to apply the borders on both cases was exactly to prevent accidental changes
> (avoiding a different layout for lwtheme), but I'm fine with it either way.
The point is that the toolbar height should remain the same as it is now, not just consistent between lwtheme and non-lwtheme.
Comment 17•14 years ago
|
||
Comment on attachment 479622 [details] [diff] [review]
Patch v2
>--- a/browser/themes/winstripe/browser/browser-aero.css
>+++ b/browser/themes/winstripe/browser/browser-aero.css
> %define customToolbarColor hsl(214,44%,87%)
>+%define aeroActiveBorderColor rgb(37, 44, 51)
>+%define aeroInactiveBorderColor rgb(102, 102, 102)
s/aero/glass/
>+ /* Artificially draw window borders that are covered by lwtheme, see bug 591930. */
>+ #main-window[chromemargin^="0,"][sizemode="normal"] > #titlebar > #titlebar-content:-moz-lwtheme {
>+ border-top-width: 2px;
>+ border-top-style: solid;
border-top: 2px solid;
>+ #main-window[chromemargin^="0,"][sizemode="normal"] > #titlebar > #titlebar-content > #appmenu-button-container:-moz-lwtheme {
>+ margin-top: -1px;
>+ }
Won't this still push the toolbars down by one pixel?
Comment 18•14 years ago
|
||
(In reply to comment #17)
> Comment on attachment 479622 [details] [diff] [review]
> Patch v2
>
> >--- a/browser/themes/winstripe/browser/browser-aero.css
> >+++ b/browser/themes/winstripe/browser/browser-aero.css
>
> > %define customToolbarColor hsl(214,44%,87%)
> >+%define aeroActiveBorderColor rgb(37, 44, 51)
> >+%define aeroInactiveBorderColor rgb(102, 102, 102)
>
> s/aero/glass/
Actually, "aero" might be correct as well, assuming it's the same border color for basic and glass. We only use it for glass, though.
Assignee | ||
Comment 19•14 years ago
|
||
> > s/aero/glass/
>
> Actually, "aero" might be correct as well, assuming it's the same border color
> for basic and glass. We only use it for glass, though.
They're different colors; I'll change to glass
{
> >+ border-top-width: 2px;
> >+ border-top-style: solid;
>
> border-top: 2px solid;
ok
>
> >+ #main-window[chromemargin^="0,"][sizemode="normal"] > #titlebar > #titlebar-content > #appmenu-button-container:-moz-lwtheme {
> >+ margin-top: -1px;
> >+ }
>
> Won't this still push the toolbars down by one pixel?
No, the border-top isn't actually pushing anything, because the height of the #titlebar-content is 23 and #titlebar is 30, so any border <= 7 doesn't make a difference.
I could add a margin-bottom: -2px (to #titlebar-content) to guarantee this in case the #titlebar shrinks in the future.
This margin-top: -1px is just to reposition the appmenu button. It's -1px rather than -2px because it's natural position (without the borders) is 1px.
Updated•14 years ago
|
Whiteboard: [has patch][needs review dao]
Updated•14 years ago
|
Attachment #479622 -
Flags: review?(dao) → review+
Assignee | ||
Comment 20•14 years ago
|
||
Follow-up needed due to landing of bug 601603, as discussed.
I've realized though that we can remove the [chromemargin^="0,"] selector from these patches as the #titlebar element is not displayed at all when the menu bar is on. Do you want me to remove them from the patches?
Attachment #484909 -
Flags: review?(dao)
Comment 21•14 years ago
|
||
(In reply to comment #20)
> Do you want me to remove them from the patches?
Yes please. Could you also merge the patches?
Assignee | ||
Comment 22•14 years ago
|
||
Sure, here is the merged patch with chromemargin selectors removed
Attachment #484909 -
Attachment is obsolete: true
Attachment #485061 -
Flags: review?(dao)
Attachment #484909 -
Flags: review?(dao)
Comment 23•14 years ago
|
||
Comment on attachment 485061 [details] [diff] [review]
Merged
>+ #main-window[sizemode="normal"] > #titlebar > #titlebar-content:-moz-lwtheme {
>+ border-top: 2px solid;
>+ -moz-border-top-colors: @glassActiveBorderColor@ rgba(255,255,255,.6);
>+ margin-bottom: -2px;
>+ }
margin-bottom: -2px; doesn't seem to make a difference. r=me with this removed or explained.
Attachment #485061 -
Flags: review?(dao) → review+
Assignee | ||
Comment 24•14 years ago
|
||
I removed the margin-bottom: -2px. It was explained in comment 19, but it's not necessary so I kept that off.
http://hg.mozilla.org/mozilla-central/rev/28d6bc4f438a
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][needs review dao]
Target Milestone: --- → Firefox 4.0b8
Updated•14 years ago
|
Target Milestone: Firefox 4.0b8 → Firefox 4.0b7
Updated•9 years ago
|
Comment 25•9 years ago
|
||
Huh, so that annoying white line is how it was designed???
Well, anyway, "border-top: 2px solid;" for Win7 causes bug 1199374
Depends on: 1199374
You need to log in
before you can comment on or make changes to this bug.
Description
•