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

VERIFIED FIXED in Thunderbird1.1

Status

VERIFIED FIXED
14 years ago
14 years ago

People

(Reporter: lokheed, Assigned: whimboo)

Tracking

({regression})

Trunk
Thunderbird1.1
x86
Linux
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(13 attachments, 5 obsolete attachments)

1.70 KB, image/png
Details
45.97 KB, image/jpeg
Details
44.33 KB, image/jpeg
Details
515 bytes, patch
Details | Diff | Splinter Review
630 bytes, patch
Details | Diff | Splinter Review
48.54 KB, image/png
Details
67.72 KB, image/png
Details
12.25 KB, image/png
Details
33.71 KB, image/png
Details
37.16 KB, image/png
Details
11.47 KB, image/jpeg
Details
1.70 KB, image/png
Details
1.13 KB, patch
benjamin
: review+
benjamin
: approval1.8b4+
Details | Diff | Splinter Review
(Reporter)

Description

14 years ago
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:
(Reporter)

Comment 1

14 years ago
Effects latest trunk build version 1.0+ (20050308)
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

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

Comment 4

14 years ago
Created attachment 178053 [details]
Screenshot of Problem

I also had the same problem in version 1.0+ (20050317), running Mandrake Linux.
 This attachment shows the problem.
funky. wonder when this regressed...
Keywords: regression
Version: unspecified → Trunk
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?
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.
Keywords: regression

Comment 8

14 years ago
We should try to get the regression window for this and figure out what broke here. 
Flags: blocking-aviary1.1?
Keywords: regression
asa, per comment 7 I tried to find a regression window but was blocked by other
(older, now fixed) bugs.

Updated

14 years ago
Status: NEW → ASSIGNED
Flags: blocking-aviary1.1?
Target Milestone: --- → Thunderbird1.1

Comment 10

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

Comment 11

14 years ago
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. 
Keywords: helpwanted
Created attachment 186959 [details] [diff] [review]
patch v1

This patch fixes the overlapping on my box.
Assignee: mscott → hskupin
Attachment #186959 - Flags: review?(mscott)
Keywords: helpwanted

Comment 13

14 years ago
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.
Attachment #186959 - Flags: review?(mscott) → review-
(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.

Created attachment 187061 [details]
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

14 years ago
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.
(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.
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.
Created attachment 187480 [details] [diff] [review]
patch v2

Ok, this should fix all menulist elements in every window of Thunderbird for
the qute theme.
Attachment #186959 - Attachment is obsolete: true
Attachment #187480 - Flags: review?(mscott)
Created attachment 187482 [details]
Screenshot with applied patch v2

Comment 21

14 years ago
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.
Created attachment 187552 [details] [diff] [review]
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.
Attachment #187480 - Attachment is obsolete: true
Attachment #187552 - Flags: review?(mscott)
Attachment #187480 - Flags: review?(mscott)

Comment 23

14 years ago
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....
Attachment #187552 - Flags: review?(mscott) → review-
Created attachment 187896 [details] [diff] [review]
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.
*** Bug 294009 has been marked as a duplicate of this bug. ***
(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.
(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.

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

Comment 29

14 years ago
Created attachment 188618 [details] [diff] [review]
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

14 years ago
Created attachment 188619 [details]
screen shot on Windows XP

here's how this looks now on my machine with the patch.
(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.
*** Bug 288223 has been marked as a duplicate of this bug. ***
Created attachment 188659 [details]
screenshots: original + patches up to now + native citizen

indubstrial gtk2 theme. the results of the last patch look ok.
(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.
Created attachment 188696 [details]
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
:)
filed bug 300127 on the general menulist dropmarker issue

Comment 37

14 years ago
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

14 years ago
Created attachment 188721 [details]
screen shot of the extra border on menu lists with patch v3
(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

14 years ago
Created attachment 188749 [details]
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]
*** Bug 300283 has been marked as a duplicate of this bug. ***

Comment 42

14 years ago
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. 
Created attachment 189103 [details] [diff] [review]
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.
Attachment #187552 - Attachment is obsolete: true
Depends on: 300127
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.
Attachment #189103 - Attachment is obsolete: true

Comment 45

14 years ago
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.
(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

14 years ago
*** Bug 297493 has been marked as a duplicate of this bug. ***
Created attachment 189628 [details] [diff] [review]
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.
Attachment #189628 - Flags: review?(mscott)
Created attachment 189629 [details]
Screenshot of native button with flat look
Created attachment 189671 [details]
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.
(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

14 years ago
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
Attachment #189628 - Flags: review?(mscott) → review+
Created attachment 189711 [details] [diff] [review]
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?
Attachment #189628 - Attachment is obsolete: true
Attachment #189711 - Flags: review?(benjamin)

Updated

14 years ago
Attachment #189711 - Flags: review?(benjamin) → review+
Attachment #189711 - Flags: approval1.8b4?

Updated

14 years ago
Attachment #189711 - Flags: approval1.8b4? → approval1.8b4+

Updated

14 years ago
Attachment #189711 - Attachment description: Patch with -moz-appearance: none for dropmarker → Patch with -moz-appearance: none for dropmarker [checked in]
Checking in menulist.css;
/cvsroot/mozilla/toolkit/themes/gnomestripe/global/menulist.css,v  <-- menulist.css
new revision: 1.4; previous revision: 1.3
done
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
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

14 years ago
*** Bug 302422 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.