Closed
Bug 512702
Opened 16 years ago
Closed 16 years ago
[Classic, Win] File button in MailNews Search Messages window is too tall due to dropmarker height
Categories
(Toolkit :: Themes, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: InvisibleSmiley, Assigned: neil)
References
Details
(4 keywords)
Attachments
(3 files)
67.02 KB,
image/jpeg
|
Details | |
835 bytes,
patch
|
InvisibleSmiley
:
ui-review+
|
Details | Diff | Splinter Review |
686 bytes,
patch
|
enndeakin
:
review+
dveditz
:
approval1.9.2.2+
dveditz
:
approval1.9.1.4+
|
Details | Diff | Splinter Review |
The File button in the MailNews Search Messages window is too tall (the other buttons are OK) with the default theme. I tracked it down to the dropmarker the height of which seems to be wrong.
I guess the dropmarker default height defined in winstripe's dropmarker.css (16px) needs an override of some kind here or is completely wrong (Modern's dropmarker.css does not define the height and neither do the other *stripe dropmarker.css files). I'm not a theme expert, though, so I don't know where that override would need to be placed.
Counter example: The dropmarkers in the MailNews toolbar do not negatively affect the height of the outer toolbarbutton, even when only using small icons and no text. The difference between the two is that the File button receives extra styling from .button-menu-dropmarker, .button-menubutton-dropmarker (buttons.css) while the toolbar buttons receives it from .toolbarbutton-menubutton-dropmarker (toolbarbutton.css).
I'd really like to see this fixed for 2.0 because I think it looks dead ugly.
Screenshot (WinXP, default theme) attached.
The button looks OK in SM 1.1.17 with the Classic theme -> regression.
Note: This might be a general issue, it's only that I found it in Search Messages.
Flags: wanted-seamonkey2?
![]() |
||
Comment 1•16 years ago
|
||
See Toolkit Bug 375930 (dropmarker too small on windows) fixed on 2007-03-31.
Adding the following to searchDialog.css works but perhaps we should put it somewhere more general?
dropmarker {
height: auto;
width: auto;
}
![]() |
||
Comment 2•16 years ago
|
||
Override the bogus rules in *stripe global/dropmarker.css introduced in Bug 375930.
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
Attachment #398356 -
Flags: ui-review?(jh)
Attachment #398356 -
Flags: superreview?(neil)
Attachment #398356 -
Flags: review?(mnyromyr)
Assignee | ||
Comment 3•16 years ago
|
||
Let's try fixing this regression at source.
Attachment #398374 -
Flags: review?(enndeakin)
Updated•16 years ago
|
Attachment #398374 -
Flags: review?(enndeakin) → review+
Reporter | ||
Comment 4•16 years ago
|
||
Comment on attachment 398356 [details] [diff] [review]
Patch v1.0 Fix bogus dropmarker CSS.
Fine with me either way. In case the Toolkit patch doesn't make mozilla-1.9.1 you may consider adopting the 11px value and adding a comment that this fix is only needed temporarily.
Note: I only checked the File button.
Attachment #398356 -
Flags: ui-review?(jh) → ui-review+
Assignee | ||
Comment 5•16 years ago
|
||
Pushed changeset 05434d7dfd53 to mozilla-central.
Assignee: philip.chee → neil
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: wanted-seamonkey2.0?
Product: SeaMonkey → Toolkit
QA Contact: themes → themes
Resolution: --- → FIXED
Assignee | ||
Comment 6•16 years ago
|
||
Comment on attachment 398374 [details] [diff] [review]
Possible patch
We'd appreciate it if you can take this safe regression fix on the 1.9.1 branch where Thunderbird 3.0 and SeaMonkey 2.0 can benefit from it. (Firefox doesn't use this particular feature which is why the bug went undetected.)
Attachment #398374 -
Flags: approval1.9.1.4?
![]() |
||
Updated•16 years ago
|
blocking1.9.1: --- → ?
status1.9.1:
--- → ?
Comment 7•16 years ago
|
||
Not blocking, but we'll still look at the approval request.
I assume attachment 398374 [details] [diff] [review] is obsolete? We should mark it so rather than leave the review requests hanging out there.
blocking1.9.1: ? → -
Comment 8•16 years ago
|
||
Comment on attachment 398374 [details] [diff] [review]
Possible patch
Approved for 1.9.1.4, a=dveditz for release-drivers
Attachment #398374 -
Flags: approval1.9.1.4? → approval1.9.1.4+
Assignee | ||
Comment 9•16 years ago
|
||
Pushed changeset 1afb366f02ff to releases/mozilla-1.9.1
Updated•16 years ago
|
Attachment #398356 -
Flags: superreview?(neil)
Attachment #398356 -
Flags: review?(mnyromyr)
Comment 10•16 years ago
|
||
Verified for 1.9.1 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090930 SeaMonkey/2.0pre.
Keywords: verified1.9.1
Assignee | ||
Comment 11•16 years ago
|
||
Comment on attachment 398374 [details] [diff] [review]
Possible patch
Regression for fix in documented feature.
Attachment #398374 -
Flags: approval1.9.2?
Assignee | ||
Comment 12•16 years ago
|
||
Comment on attachment 398374 [details] [diff] [review]
Possible patch
I must need sleep...
Assignee | ||
Comment 13•16 years ago
|
||
Comment on attachment 398374 [details] [diff] [review]
Possible patch
Fix for regression in documented feature.
Assignee | ||
Comment 14•15 years ago
|
||
Comment on attachment 398374 [details] [diff] [review]
Possible patch
Pushing approval request to the next branch release.
These changes do not affect Firefox, although they may improve the appearance of some Firefox extensions.
Attachment #398374 -
Flags: approval1.9.2.1?
Updated•15 years ago
|
Attachment #398374 -
Flags: approval1.9.2?
Comment 15•15 years ago
|
||
Comment on attachment 398374 [details] [diff] [review]
Possible patch
Approved for 1.9.2.2, a=dveditz
Attachment #398374 -
Flags: approval1.9.2.2? → approval1.9.2.2+
Assignee | ||
Comment 16•15 years ago
|
||
Pushed changeset f27b664528b4 to releases/mozilla-1.9.2
status1.9.2:
--- → .2-fixed
Comment 17•15 years ago
|
||
Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4
Keywords: verified1.9.2
You need to log in
before you can comment on or make changes to this bug.
Description
•