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.
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.
Keywords: nsbeta1, regression
have fix in hand. re-assigning to varada.
Assignee: ducarroz → varada
Created attachment 99588 [details] [diff] [review] 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 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.
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.
Created attachment 99788 [details] [diff] [review] Patch V1.1 Checking for the state of the View menu's checked attribute and then showing the toolbar.
Attachment #99588 - Attachment is obsolete: true
Comment on attachment 99788 [details] [diff] [review] Patch V1.1 looks good r=srilatha
Attachment #99788 - Flags: review+
Neil, does that last patch work for you?
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.
Created attachment 100427 [details] [diff] [review] 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.
Attachment #99788 - Attachment is obsolete: true
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.
Attachment #100427 - Flags: review+
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Using trunk build 20021118 on winxp, macosx, and linux this is fixed. verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.