169255 - Menu change to Plain Text fomat leaves subsquent HTML compose windows with a hidden Format tool bar

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[esther]

Using trunk build 20020917 on winxp (didn't happen on linux still testing mac),
if I override an HTML compose window using the Menu Option to send in Plain text
this time only, subsquent HTML compose windows do not display the Formatting
Tool bar.
There was a bug fix (77221) to hide the toolbar when a user selects the Plain
text option from the menu, this may have cause this bug.  

1. Launch app 
2. Launch Mail (have a mail account set to compose in HTML)
3. Select the mail account set to compose in HTML and click New Msg
4. Select from the menu Options|Format|Plain Text Only, then close the compose
window.
5. Select New Msg again

Result: A compose window comes up without the HTML formatting tool bar (this is
not a plain text compose window because the menu options for changing the Format
are available, they would not be available if this were a Plain text compose
window).
Expected:  An compose window with the HTML formatting tool bar present.

Comment 1

[esther]

Nominating because it's not obvious how to get the HTML compose window back
during this session.  Exiting the app will bring it back, so will selecting the
Format menu option to send in HTML. 

Comment 2

[varada]

have fix in hand. re-assigning to varada.

Comment 3

[varada]

Attachment: Patch V1.0

resetting the toolbars' hidden attribute when we close the window so that when
we recycle we dont carry over the same values for the attribute.

Comment 4

[[e-mail]]

Comment on attachment 99588 [details] [diff] [review]
Patch V1.0

I think this patch regresses the case when the toolbar has been manually hidden
via the view menu. Perhaps you could replace gSendFormat =
nsIMsgCompSendFormat.AskUser with  OutputFormatMenuSelect(
document.getElementById( "format_auto" ) ) in InitializeGlobalVariables
instead.

Comment 5

[[e-mail]]

Oops, that doesn't work either because a) the nodes don't exist yet and b)
OutputFormatMenuSelect (uselessly) tests for gMsgCompose. Perhaps you can call
it when recycling, but you might still have to remove the useless dependencies.

Comment 6

[varada]

Attachment: Patch V1.1

Checking for the state of the View menu's checked attribute and then showing
the toolbar.

Comment 7

[Srilatha Moturi]

Comment on attachment 99788 [details] [diff] [review]
Patch V1.1

looks good
r=srilatha

Comment 8

[David :Bienvenu]

Neil, does that last patch work for you?

Comment 9

[[e-mail]]

Comment on attachment 99788 [details] [diff] [review]
Patch V1.1

I haven't tried the patch yet but I just noticed that it would be preferable if
you used .hidden as it saves passing the string "hidden" across XPCOM every
time.

Comment 10

[varada]

Attachment: Patch V 1.2

Have changed to using .hidden -thanks for the suggestion neil. This and the
previous patch addresses the problem of showing the possible hidden menus if
the user set the option format to plaintext in the first compose window as well
as check for the instance when the user might have set the view of toolbar to
be hidden and taken care of the same.

Comment 11

[[e-mail]]

Comment on attachment 100427 [details] [diff] [review]
Patch V 1.2

Marking as reviewed because the only changes from the reviewed patch are the
use of .hidden and I've checked that they work the same. In fact I've tried
this patch with every combination of open and closing messages with and without
the toolbar both using the view menu and the format menu and it got it right
every time.

Comment 12

[David :Bienvenu]

Comment on attachment 100427 [details] [diff] [review]
Patch V 1.2

thx, neil, sr=bienvenu

Comment 13

[varada]

Marking Fixed.

Comment 14

[esther]

Using trunk build 20021118 on winxp, macosx, and linux this is fixed. verified