All users were logged out of Bugzilla on October 13th, 2018

Sizes of some XUL elements changes when lightweight themes are applied

RESOLVED FIXED in mozilla36

Status

()

RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: neil, Assigned: neil)

Tracking

Trunk
mozilla36
x86_64
Windows Server 2008
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

8 years ago
Unlike Firefox, we don't override the borders of our toolbars and menus. So when lightweight themeing turns them off, their size changes, which is ugly and hopefully unintentional. The size of statusbarpanels also changes, but I haven't investigated them yet.
(Assignee)

Comment 1

8 years ago
Created attachment 457704 [details] [diff] [review]
Possible patch
Attachment #457704 - Flags: review?
(Assignee)

Updated

8 years ago
Attachment #457704 - Flags: review? → review?(dao)
Comment on attachment 457704 [details] [diff] [review]
Possible patch

I don't think we want the border visually, so this should probably use border-color: transparent instead...
Comment on attachment 457704 [details] [diff] [review]
Possible patch

Also, how will this affect cases where the border wasn't actually used without the lightweight theme due to -moz-appearance?
(Assignee)

Comment 4

8 years ago
(In reply to comment #2)
> I don't think we want the border visually, so this should probably use
> border-color: transparent instead...
Sure, I can switch winstripe to border-color: transparent if you prefer.

(In reply to comment #3)
> Also, how will this affect cases where the border wasn't actually used without
> the lightweight theme due to -moz-appearance?
Well, only winstripe provides a CSS border, so if the other themes still change size then I guess they'll need to add a CSS border width.
(Assignee)

Comment 5

8 years ago
Created attachment 457823 [details]
Screen shot with borders

Personally I don't think there's anything wrong with keeping the borders. At least this way the application can turn them off it doesn't want them.

Updated

8 years ago
Attachment #457823 - Attachment is patch: false
Attachment #457823 - Attachment mime type: text/plain → image/png
(In reply to comment #4)
> (In reply to comment #3)
> > Also, how will this affect cases where the border wasn't actually used without
> > the lightweight theme due to -moz-appearance?
> Well, only winstripe provides a CSS border, so if the other themes still change
> size then I guess they'll need to add a CSS border width.

This doesn't seem to answer my question. Winstripe specifies a CSS border, but that border isn't used in case of -moz-appearance:toolbar, so it looks like your patch will increase the toolbar height rather than maintaining it.
(Assignee)

Comment 7

8 years ago
(In reply to comment #6)
> This doesn't seem to answer my question. Winstripe specifies a CSS border, but
> that border isn't used in case of -moz-appearance:toolbar, so it looks like
> your patch will increase the toolbar height rather than maintaining it.
Which OS is this on? My toolbars on XP have borders with Luna or Classic.
I'm not sure about various third-party OS themes in general. Luna draws borders, but do these actually occupy space like the CSS borders would?
(Assignee)

Comment 9

8 years ago
Created attachment 460328 [details] [diff] [review]
Proposed patch

OK, so comparing with gnomestripe we should make the borders transparent.

Tested on both Classic and Luna.
Assignee: nobody → neil
Attachment #457704 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #460328 - Flags: review?(dao)
Attachment #457704 - Flags: review?(dao)
Comment on attachment 460328 [details] [diff] [review]
Proposed patch

It's still not fully clear to me that this will do the right thing when switching from non-lwtheme (-moz-appearance:toolbar, no CSS border rendered) to lwtheme (-moz-appearance:none, transparent CSS border rendered), but rs=me
Attachment #460328 - Flags: review?(dao) → review+
https://hg.mozilla.org/mozilla-central/rev/be49c680d2f5
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36

Comment 13

4 years ago
This patch caused 2 bugs:
1 - on a maximized window, there is now a space above the tabs - so just moving the cursor to the top of the window and clicking won't select a tab, which is a bit annoying... having to target the tab.
2 - there is a white line between the current tab and the rest of the window.
This bugs happen when using a lw-theme. Normal theme has no problems.
(In reply to Guilherme Lima from comment #13)
> This patch caused 2 bugs:
> 1 - on a maximized window, there is now a space above the tabs - so just
> moving the cursor to the top of the window and clicking won't select a tab,
> which is a bit annoying... having to target the tab.
> 2 - there is a white line between the current tab and the rest of the window.
> This bugs happen when using a lw-theme. Normal theme has no problems.

Could you please file a new bug on this and make it block this one? Thanks.

Updated

4 years ago
Depends on: 1101495
(In reply to Dão Gottwald [:dao] from comment #14)
> (In reply to Guilherme Lima from comment #13)
> > This patch caused 2 bugs:
> > 1 - on a maximized window, there is now a space above the tabs - so just
> > moving the cursor to the top of the window and clicking won't select a tab,
> > which is a bit annoying... having to target the tab.
> > 2 - there is a white line between the current tab and the rest of the window.
> > This bugs happen when using a lw-theme. Normal theme has no problems.
> 
> Could you please file a new bug on this and make it block this one? Thanks.

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