241073 - formatting toolbar goes crazy when there is some error while delivering mail

Status: VERIFIED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Neeme Praks]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla Thunderbird 0.5+ (20040413)

If either I cancel the delivery of an email or there some error occurs while
delivering an email, the formatting toolbar occupies half of the compose window
when the focus returns to the compose window, after the error/cancellation.

How to get back the normal size toolbar?
If you move your mouse over the toolbar, then at some mouseover of a button
event, the toolbar restores its original size.

But this happens occasionally, not always.
And this never happened with 0.5 release, started happening when I upgraded to a
nightly build.

Reproducible: Sometimes
Steps to Reproduce:
1. compose a new message
2. try to send it
3. either cancel the delivery or produce some error (unplug the net?)
4. press all the [ok] buttons to get back to compose window
Actual Results:  
when you get back to compose window, sometimes the toolbar goes crazy and fills
half of the compose window (I'll also attach a screenshot).

Expected Results:  
toolbar should stay with normal size.

Comment 1

[Neeme Praks]

Attachment: screenshot

screenshot that shows the resulting toolbar

Comment 2

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

WFM Mozilla Thunderbird 0.6+ (20040419)

Do you have created a fresh profile and tested there?

Comment 3

[Scott MacGregor]

I can't reproduce this but I know the checkin changes that caused it. It had to
do with the CSS changes for the new smiley icons. 

I'll target this for 0.6 in the hopes that someone can figure out the mistake I
made and make this work. Otherwise it'll get bumped to 0.7

I'm not able to reproduce it myself. But I'm not doubting you. 

Comment 4

[Scott MacGregor]

this is the checkin I made that causes this:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=messengercompose.css&branch=&root=/cvsroot&subdir=mozilla/mail/components/compose/skin&command=DIFF_FRAMESET&rev1=1.27&rev2=1.28

Comment 5

[Scott MacGregor]

Attachment: the fix

this trys to solve the problem I was originally fixing in a better way that
doesn't caue this regression.

Comment 6

[Scott MacGregor]

fixed for .6 and on the trunk

Comment 7

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

Scott, the new icons are stored within one bitmap file with a height of 310px.
This is exact the same size of the miss-drawn formatting toolbar. How do you
handle "list-style-image: url("chrome://editor/skin/icons/btn2.gif");"? With CSS
you can't grab one icon out there. AFAIK every time the whole list-image is
drawn. But why the icons aren't visible on the attached screenshot?

Comment 8

[Neeme Praks]

One more comment about when the toolbar restores the original size.
Originally I wrote:
"If you move your mouse over the toolbar, then at some mouseover of a button
event, the toolbar restores its original size."

The mouseover button in question is the smiley button (pulldown) that is not
really visible on the screenshot. So I guess you're right when you say that it
has to do with those new smileys. Why they are not visible... don't know.

But on opening a new compose window there seems to be the same effect, although
for a very short while: there is some "flickering" that seems like the toolbar
is very big in the beginning and then it is very quickly resized to the normal
height.

Comment 9

[Scott MacGregor]

re-opening. I have a better fix for this

Comment 10

[Scott MacGregor]

Attachment: better fix

this fix actually adds the smiley menu PNG's to the editor format bar. I made a
new image that replaces editor's btn2.gif with format-toolbar.png which
contains the new menu smileys in addition to the old artwork for the editor
toolbar.

Comment 11

[Scott MacGregor]

this better fix is now checked into the 0.6 branch, the 1.7 branch and the trunk.

Comment 12

[Scott MacGregor]

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