285288 - Arrow overlaps "To:, Cc: Bcc:" etc. in compose new message window

Status: VERIFIED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Max Powers]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050308 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050308 Firefox/1.0+

The down arrow overlaps the text in all To:, Cc:, Bcc, etc. localized in the
compose new message window.

Reproducible: Always

Steps to Reproduce:
1.Compose new message
2.
3.

Actual Results:  
Arrow overlaps text fields before senders email

Expected Results:  
Arrow should trail text such as To: and Cc:

Comment 1

[Max Powers]

Effects latest trunk build version 1.0+ (20050308)

Comment 2

[Tracy Walker [:tracy]]

confirmed with trunk build 2005-03-18-05-trunk on Linux.  There is an unwanted
caret stacked in the text [To:] box in message compose.

Comment 3

[Greg Onufer]

Confirmed on my own trunk builds for Solaris 8 SPARC and Solaris 10 x86.

Comment 4

[Joel Nackman]

Attachment: Screenshot of Problem

I also had the same problem in version 1.0+ (20050317), running Mandrake Linux.
 This attachment shows the problem.

Comment 5

[sairuh (rarely reading bugmail)]

funky. wonder when this regressed...

Comment 6

[sairuh (rarely reading bugmail)]

looks like this was a problem since 2005-02-07. I'll get a narrower window.

could this be a new issue with the default theme?

Comment 7

[sairuh (rarely reading bugmail)]

hrm, the 2005-01-15-trunk build shows this bug. I tried trunk builds from
2005-01-01 and 2004-12-15, but they exhibited the old "no menus, useless UI" bug
272621 and bug 276918.

Comment 8

[Asa Dotzler [:asa]]

We should try to get the regression window for this and figure out what broke here. 

Comment 9

[sairuh (rarely reading bugmail)]

asa, per comment 7 I tried to find a regression window but was blocked by other
(older, now fixed) bugs.

Comment 10

[Scott MacGregor]

*** Bug 297368 has been marked as a duplicate of this bug. ***

Comment 11

[Scott MacGregor]

Could it be as simple as the padding being off in this widget? I don't have
access to a linux box to easily reproduce this. 

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: patch v1

This patch fixes the overlapping on my box.

Comment 13

[Scott MacGregor]

Comment on attachment 186959 [details] [diff] [review]
patch v1

thanks for helping out with this bug.

I didn't like what this did (style wise) to the To/cc box, it made them look
like big dark buttons instead of the white background they have today.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #13)
> I didn't like what this did (style wise) to the To/cc box, it made them look
> like big dark buttons instead of the white background they have today.

Scott, now I see what you mean. Not only the To/Cc box is affected. Also the
from dropdown list gets a dark grey color. I will take a look again today, and I
will modify the patch.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: screenshot of modified menulist style

Scott, I looked a little bit closer to the problem. I noticed that every
menulist element has changed it's style. Please take a look at the attachment.
It doesn't only occur in a compose window, instead the whole application is
affected. IMO the global style of menulist was changed?

Comment 16

[Scott MacGregor]

cc'ing myself

Henrik, the menu lists in the compose window look fine with me until I run with
the patch. Once I do that, then I see the menu list look like a dark button
because the patch changes the autcomplete menulists to look like buttons. It
wasn't a global change, just a change to the widgets in that window and only
when I run with the patch you pointed out. Note: I'm on windows.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #16)
> Henrik, the menu lists in the compose window look fine with me until I run with
> the patch. Once I do that, then I see the menu list look like a dark button
> because the patch changes the autcomplete menulists to look like buttons.

Scott, sorry for confusion but my last question doesn't point to my changes. I
already revert it on my local tree. Please take a look at the attached
screenshot. What you will see is the current compose window under Linux. Every
menulist (not only within that window) has an additional dropdown icon on the
right side. It's laying behind the menulist-dropmarker. Within the compose
window the menulist-dropmarker is moved to the left side due to the class
menulist-compact. I think there were changes since TB 1.0.x. I'll take a look on
that later today.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, i figured out the problem. This problem started with the initial checkin of
the qute theme for the trunk by Ben. 

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/toolkit/themes/qute/global&command=DIFF_FRAMESET&file=menulist.css&rev1=1.1&rev2=1.2&root=/cvsroot

A patch will follow immediately.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: patch v2

Ok, this should fix all menulist elements in every window of Thunderbird for
the qute theme.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Screenshot with applied patch v2

Comment 21

[Scott MacGregor]

Comment on attachment 187480 [details] [diff] [review]
patch v2

I noticed that winstripe, classic and modern all have:

menulist {
 -moz-appearance: menulist;

I wonder why none of those themes have this problem.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: patch v3 with flat look

(In reply to comment #21)
> I wonder why none of those themes have this problem.

Probably a side-effect of native theming? 

After a small discussion on IRC I made an enhancement to my last patch. Now the
addressing-widget is displayed in flat style. There is no button for the
dropdownmarker. Only an arrow is shown, which makes it sweeter IMO.

Comment 23

[Scott MacGregor]

Comment on attachment 187552 [details] [diff] [review]
patch v3 with flat look

this still altered the appearance on Windows. I'd like to just fix the problem
with the the text and the arrow overlapping without changing the look of the
menu list. I'm also not sure that removing the menulist appearance of a menu
list is a good thing to do.

I'm still confused as to why the other themes don't have this problem, there
CSS style rules for a menulist look just like the one in menulist.css.	It's
not a native themeing difference because qute, winstripe and classic are all
using the same themeing for menu lists....

Comment 24

[Tuukka Tolvanen (sp3000)]

Attachment: patch a2: inherit background on label

You probably only want to touch .menulist-compact and its contents, not the
general menulist style?

The dropmarker on the left is a xul dropmarker; the label-overlapping
dropmarker on the right comes from the gtk2 theme, and changes appearance with
gtk theme. All menulist widgets have the native graphics lurking but mostly (or
completely, depending on gtk theme) obscured by the xul dropmarker because it
is placed on the right; see e.g. the "From:" dropdown in attachment 187061 [details].

The correct fix I guess would involve getting rid of the xul dropmarkers where
they don't have some special purpose, or making them transparent, and getting
the label to avoid the native dropmarker graphics properly and
platform-dependently...

One option is to put e.g. margin-right: 23px on the label, but that's a fake
one-size-fits all number and a wrong rule on windows anyway. Another is to set
a background on the label to blot out the native dropmarker (messes with
gradient bg and focus rings). This candidate patch takes the second approach --
it's bearable on some gtk themes.

Comment 25

[Mike Cowperthwaite]

*** Bug 294009 has been marked as a duplicate of this bug. ***

Comment 26

[Mike Cowperthwaite]

(In reply to comment #16)
> Henrik, the menu lists in the compose window look fine with me until I run
> with the patch. Once I do that, then I see the menu list look like a dark
> button because the patch changes the autcomplete menulists to look like
> buttons.

In my opinion, that difference is highly desirable.  The current appearance of 
the qute theme addressing dropdowns is not good, in my opinion; the appearance 
in attachment 187482 [details] looks much better.  See bug 184811 comment 5: 
that implements the same    -moz-appearance: none !important;    rule as 
attachment 187061 [details], only with less of a global scope; and it was specifically 
designed to make those dropdowns look like buttons.  (Scott commented at that 
bug that he "couldn't see the difference" but here -- comment 14 and comment 23 
-- he apparently prefers the current appearance.)

One problem with the current appearance is that when the focus is on the 
dropdown, there is no visible indicator; this problem is resolved using the 
button-like (-moz-appearance:none) rule.


> Note: I'm on windows.

The particular problem of overlapping text & widget in this bug appears to be 
Linux-only -- at least, I haven't seen reports from any other platform.


Bug 288223 is probably a dupe of this, but bug 288223 comment 4 states that the 
symptom is also seen in the Suite's Classic theme.

Comment 27

[sairuh (rarely reading bugmail)]

(In reply to comment #26)
> Bug 288223 is probably a dupe of this, but bug 288223 comment 4 states that the 
> symptom is also seen in the Suite's Classic theme.

I see this issue using the default Tbird theme, but I don't see it when using
Charamel 0.93.

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+1]]

*** Bug 299972 has been marked as a duplicate of this bug. ***

Comment 29

[Scott MacGregor]

Attachment: variation of the suggested fix

Ok, Mike has me convinced to at least try it :)

How about this patch. Similar to Henrik's patch except I localized the change
to just the autocomplete menu list. Screen shot coming up.

Comment 30

[Scott MacGregor]

Attachment: screen shot on Windows XP

here's how this looks now on my machine with the patch.

Comment 31

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #30)
> here's how this looks now on my machine with the patch.

It's nice yeah, but it doesn't solve the issues at all. Take a look at
attachment 187061 [details]. The style of the "From:" dropdown is broken for the whole UI.
It really look's ugly. My patch v3 solves it everywhere.

Comment 32

[Karsten Düsterloh]

*** Bug 288223 has been marked as a duplicate of this bug. ***

Comment 33

[Tuukka Tolvanen (sp3000)]

Attachment: screenshots: original + patches up to now + native citizen

indubstrial gtk2 theme. the results of the last patch look ok.

Comment 34

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #33)
> indubstrial gtk2 theme. the results of the last patch look ok.

No, definitely not! Read my comment 31. You will see the same behavior with the
"From:" menulist. There is a border around the dropmark, which shouldn't be
there! Also a small piece of the underlaying arrow is visible on the left side
of the dropmark. This I solved with patch v2 and v3. 

If you would ask me, I would tell that patch v2 is the best choise. Flat style
isn't acceptable because then we should use it for the whole UI and not only for
the adressingWidget.

Comment 35

[Tuukka Tolvanen (sp3000)]

Attachment: gtk2 screenshot: .menulist-dropmarker { display: none }

For reference, here's a screenshot with what I think should be the desired
appearance (as in, exactly native) for menulists in general, by using
userChrome.css:
    .menulist-dropmarker { display: none }
    .aw-menulist > .menulist-dropmarker { display: -moz-box }
on top of attachment 188618 [details] [diff] [review]: variation of the suggested fix.

Patches v2 and v3 seem to solve the minor duplicate dropmarker overlap issue by
reverting to tb1.0's completely non-native look for menulists in general; I
don't think that's the right direction to go. Instead, what
http://lxr.mozilla.org/mozilla/source/toolkit/themes/gnomestripe/global/menulist.css#67
wants to do for fx on gtk -- turn off the redundant xul dropmarker, following
the native theme properly. (Incidentally, gnomestripe menulist.css packaging is
broken atm so the issue exists in fx as well.) As far as I understand, there's
no separate css for gtk and windows for thunderbird, and as such that fix would
break windows (it does at least w98 1.1a1 which I have available).

The latest patch seems to handle the more pressing text overlap issue in the
specially styled compose header menulists in a way that breaks neither windows
or gtk, nor requires platform-specific css for decent results. So IMO that's
all good and the duplicate-dropmarker issue should be a subject for another bug
:)

Comment 36

[Tuukka Tolvanen (sp3000)]

filed bug 300127 on the general menulist dropmarker issue

Comment 37

[Scott MacGregor]

I'm not interested in the button look at all (patch v2). So that leaves us with
patch v3 with the flat look if we cannot isolate the change to just mail compose.

In that scenario, I like the flat look for autocomplete widgets in patch v2
(thanks for the pictures Tuuka, that helped a lot). However, on windows it
regresses menu lists boxes. They now get a dark drop border around the top and
the left hand side which wasn't there before. That's why I was not in favor of a
global change because it has adverse UI effects (at least on Windows). Screen
shot coming up to show the extra drop shadow / border on menulists.

Comment 38

[Scott MacGregor]

Attachment: screen shot of the extra border on menu lists with patch v3

Comment 39

[Mike Cowperthwaite]

(In reply to comment #37)
> In that scenario, I like the flat look for autocomplete widgets in patch v2
> (thanks for the pictures Tuuka, that helped a lot). However, on windows it
> regresses menu lists boxes. They now get a dark drop border around the top and
> the left hand side which wasn't there before. That's why I was not in favor of 
> a global change because it has adverse UI effects (at least on Windows).
> Screen shot coming up to show the extra drop shadow / border on menulists.

I'm confused: I'm running TB (under Win2K) with no theming at all, except for a 
userChrome rule implementing (as !important) the CSS from attachment 188618 [details] [diff] [review].  
Even removing that, I *always* see that drop shadow/border on menulists 
(MailView, From:, listboxes in Options, etc).

Comment 40

[Scott MacGregor]

Attachment: screen shot of Windows XP menu lists (unpatched!)

Mike, here's how menu lists look on Windows XP (without any menu list patches).
Note the clean lines around the view menu without any drop shadow when compared
to attachment 188721 [details]

Comment 41

[Boris Zbarsky [:bzbarsky]]

*** Bug 300283 has been marked as a duplicate of this bug. ***

Comment 42

[Scott MacGregor]

If we're going to make this a global menu list change, then what I'm looking for is:

1) A patch that yields the results of patch v3
2) But without the negative menu listbox side effects on Windows XP that I show
in attachment 188721 [details]

If we can meet both of those criteria then we'll be good to go. 

Comment 43

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: patch v3 with no side-effect

Scott, we don't use "-moz-appearance: listbox;" instead? This will remove
completely the additional dropdown array within the whole UI and your side
effect doesn't occur under WinXP.

Comment 44

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Comment on attachment 189103 [details] [diff] [review]
patch v3 with no side-effect

We shouldn't make modifications within the qute theme. When bug 300127 is fixed
we are able the change gnomestripe without any effect for other OS.

Comment 45

[Scott MacGregor]

wow good timing as I was in the process of committing your patch which met all
of my goals before you obsoleted it :)

In that case, I'm still interested in bringing the flat look to the compose
window. Assuming we fix menulists in gnomestripe, then we could go all the way
back to my variation of the suggested fix which styled just the autocomplete
menulist wit the flat look.

Comment 46

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #45)
> wow good timing as I was in the process of committing your patch which met all
> of my goals before you obsoleted it :)

Yeah, I had such a feeling and so I hurried up. ;)

> In that case, I'm still interested in bringing the flat look to the compose
> window. Assuming we fix menulists in gnomestripe, then we could go all the way
> back to my variation of the suggested fix which styled just the autocomplete
> menulist wit the flat look.

With the fix of bug 300127 the general style of menulist elements are working
now for gnomestripe. The only part where we have to work on is menulist-compact.
This style is still broken. I hope that I can offer a solution this evening.

Comment 47

[Adam Guthrie]

*** Bug 297493 has been marked as a duplicate of this bug. ***

Comment 48

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Flat look for menulist-compact

This patch will turn the menulist-compact into a native button with flat look.
I had to add the list-style-images again but only for dropmarkers of
menulist-compact.

Comment 49

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Screenshot of native button with flat look

Comment 50

[Mike Cowperthwaite]

Attachment: Win2K/qute with proposed patch

I incorporated the critical CSS from that patch into my userChrome.css --
here's a screenshot of the compose window's widget.  I *hate* the button
appearance of the dropmarker.  I prefer this:

.menulist-compact {
   -moz-appearance: button;
}
 
.menulist-compact > .menulist-dropmarker {
   -moz-appearance: none;
}

This yields the same "flat look" that 

If a button-like dropmarker is desirable for some people, it should be put into
a theme or userChrome.css.

Comment 51

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #50)
> I incorporated the critical CSS from that patch into my userChrome.css --
> here's a screenshot of the compose window's widget.  I *hate* the button
> appearance of the dropmarker.  I prefer this:

Mike, the patch is gnomestripe only and was not created to be used with qute! So
if using qute your mentioned changes should be used.

Comment 52

[Scott MacGregor]

Comment on attachment 189628 [details] [diff] [review]
Flat look for menulist-compact

You'll need a review from a toolkit peer as well like bryner or bsmedberg

Comment 53

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Patch with -moz-appearance: none for dropmarker [checked in]

I updated -moz-appearance for the dropmarker to "none" due to it's not a native
widget. So we are sync with Mikes proposal for win32.

Benjamin, can you give a second review?

Comment 54

[Karsten Düsterloh]

Checking in menulist.css;
/cvsroot/mozilla/toolkit/themes/gnomestripe/global/menulist.css,v  <-- menulist.css
new revision: 1.4; previous revision: 1.3
done

Comment 55

[Mike Cowperthwaite]

Personally, I think those two CSS rules changing the '-moz-appearance' attribute 
should have been added to messenger.css rather than a theme-specific file.  
Since they haven't, I've opened bug 301465 about porting those rules to qute.

Comment 56

[Adam Guthrie]

*** Bug 302422 has been marked as a duplicate of this bug. ***