Closed
Bug 579208
Opened 14 years ago
Closed 10 years ago
Sizes of some XUL elements changes when lightweight themes are applied
Categories
(Toolkit :: Themes, defect)
Tracking
()
RESOLVED
FIXED
mozilla36
People
(Reporter: neil, Assigned: neil)
References
Details
Attachments
(2 files, 1 obsolete file)
185.74 KB,
image/png
|
Details | |
1.98 KB,
patch
|
dao
:
review+
|
Details | Diff | Splinter Review |
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•14 years ago
|
||
Attachment #457704 -
Flags: review?
Assignee | ||
Updated•14 years ago
|
Attachment #457704 -
Flags: review? → review?(dao)
Comment 2•14 years ago
|
||
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 3•14 years ago
|
||
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•14 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•14 years ago
|
||
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•14 years ago
|
Attachment #457823 -
Attachment is patch: false
Attachment #457823 -
Attachment mime type: text/plain → image/png
Comment 6•14 years ago
|
||
(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•14 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.
Comment 8•14 years ago
|
||
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•14 years ago
|
||
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 10•10 years ago
|
||
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+
Comment 12•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/be49c680d2f5
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Comment 13•10 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.
Comment 14•10 years ago
|
||
(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.
Comment 15•10 years ago
|
||
(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.
Description
•