Moved this bug from Bugscape bug http://bugscape.netscape.com/show_bug.cgi?id=2262 Saw this all platforms: Win32 2000-09-07-06 M18 Mac 2000-09-07-04 M18 Linux 2000-09-07-08 M18 1) Launch seamonkey and invoke Composer via Tasks-->Composer 2) Type some text in a new compose window. 3) Click the Save icon on Composer toolbar. 4) Give the file a name in the densuing dialog. Click OK. 5)In the "Save Page As" dialog which then appears, pull down option to "Save as type" and select "Text Files" 6)Click on "Save" button. 7)Open the file you just saved in a text editor. Actual results: When the file is saved, and opened in a text editor, it has html tags all over it (whether or not "Save as Text" was selected). Nominating nsbeta3 as implied functionality not present. Another way to repro: 1)Launch seamonkey and login to IM via Sidebar buddy list, or IM standalone 2)Invoke a chat session invite window via clicking on the Chat icon on the Online tab. Send an invite to a buddy and have them accept 3)Send messages back and forth 4)Click on the the Save icon on the Chat session toolbar. Nominating nsbeta3 - For businesses using chat, I don't feel it will be uncommon to attempt to save these files as text for meeting notes (shrimp), though a workaround would be to open the file in Composer for NS6 and save as text from there, it adds unwanted steps to this procedure. ------- Additional Comments From beppe@netscape.com 2000-09-07 14:58 ------- assigning to akkana for review ------- Additional Comments From Akkana 2000-09-07 15:09 ------- This isn't a problem with the output system -- sounds like someone didn't hook up Save As Text correctly. I'm not sure who owns that. I could look at it if nobody else has time and if we think it's beta3. Why is this a bugscape vs. bugzilla issue? ------- Additional Comments From Simon Fraser 2000-09-07 15:28 ------- Do we really have a popup in the save dialog to specify file type? I'm pretty sure there isn't one on Mac. Maybe this is a file picker issue, and it's showing the file type popup when it should not. ------- Additional Comments From Charles Manske 2000-09-07 15:37 ------- No, we should pay attention to the file filter or extension (I think we did just the later in 4.x) Currently nsEditorShell::SaveDocument simply ignores the resulting file filter or file extension and just saves as HTML. This should be a bugzilla bug. I might have time to look at this after the rest of my bugs are finished. Does the SaveAs in Navigator work corrrectly when "text" is selected?

I'll log a separate bug for the Mac if I don't find another, It only saves in html (doesn't show that it does this in dialog though, only gives option to "save").

Save As in Navigator on Win32 and Linux only has option to "Save as files of type "All Files" in todays builds 9/7/00

Changing owner to akkana@netscape.com per Beppe's comment

Looks like all the modules dropped the ball on this one. We used to pay attention to the file extension and do the appropriate conversion -- basically, do HTML output if extension is ".html", ".htm", or ".shtml", and text for anything else. I totally agree with the original bug filer that saving as text is a very important feature. It really shouldn't be too hard to do since the output routines work fairly well for text. Akkana: isn't that so?

Yes, plaintext output works fine (or else we'd be in big trouble for mail). Charley, did you say you might be able to take this bug? I don't know anything about the code involved.

Sure, but it would be a later priority.

scalkins@netscape.com: Why is this a netscape-only bug? Surely this bug should be readable by everyone? I see it mentions AIM, but it doesn't give away any confidential information, and the primary focus of this bug is not AIM, so...?

ok, opening to world... Chat is in latest betas anyhoo

yes, this is in both browser and Composer, it's just not feasible to get this in before b3, marking this as nsbeta3- for now and setting to future

I'd like to nominate this for 6.5. It affects aim for Chat sesions.

See also bug 47640.

Setting milestone to fix for next release

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

This is a regression - it worked some months ago. Bug 42441 (for navigator) is related, might technically be a dup of this one.

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

Discussions by email on this feature reveals the problems of using the file type combobox (menulist) in the OS-specific file picker dialog as the user's way of telling us what type of output they want, HTML or text. There is also the issue that after saving to a text file, we don't turn into a plain text editor (i.e., subsequent "Save" doesn't save as text). In many programs, this difference is indicated by a separate "Save Copy..." menu item, such as in most Adobe programs. The attachment adds the separate menu item "Save a Copy as Text..." Simon prefers something like: "Export to Text..." This is open for discussion.

Comments: + if (aFormat == NS_LITERAL_STRING("text/html")) Avoid string operators if possible. Better to use .Equals here. NS_IMETHODIMP nsEditorShell::GetEditorType(PRUnichar **_retval) { - *_retval = nsnull; - - nsresult err = NS_NOINTERFACE; - nsCOMPtr<nsIEditor> editor = do_QueryInterface(mEditor); - - if (editor) - { + if (!_retval) return NS_ERROR_NULL_POINTER; *_retval = mEditorTypeString.ToNewUnicode(); - } - return err; + + return NS_OK; } What are these changes doing here? + title.AppendWithConversion("*"); Better as title.Append(PRUnichar('*')); + fileName.AppendWithConversion(".txt"); Better as fileName.Append(NS_LITERAL_STRING(".txt")); Ditto for + format.AssignWithConversion("text/plain"); + // Rebuild Recent Pages menu and save any changed URLs or titles to editor prefs + nsAutoString commandName(NS_LITERAL_STRING("cmd_buildRecentPagesMenu")); + return DoControllerCommand(commandName); Where did 'cmd_buildRecentPagesMenu' come from? Commands should only be used for user-oriented tasks, not general book-keeping. + // Also rebuilds the "Recent Pages" menu and + // saves history of URLs, titles to prefs + nsresult UpdateWindowTitleAndRecentMenu(); Does this have to be in C++? + gHTMLEditorCommandManager.registerCommand("cmd_buildRecentPagesMenu", nsBuildRecentPagesMenu); I don't think this should be a command. +<!ENTITY saveCopyAsTextCmd.label "Save a Copy as Text..."> Eek, too long for a menu item. How about "Export as Text". I'd prefer to see all the commands etc. renamed to 'cmd_exportText' too.

sr=sfraser

> Avoid string operators if possible. Better to use .Equals here. Why? Shouldn't it be equivalent?

String equality operators are being deprecated, because they often involve implicit conversions between wide and narrow strings. They also confuse people.

> String equality operators are being deprecated I'm definitely in the wrong project. (Nothing to do with you personally, sfraser.)

Response to sfraser's review: Brade didn't like using "Export..." at all for the strings (although I thought it was ok.) I'll make the suggested string-related changes. The reason I made a "BuildRecentMenu" command is so we could access the same code we use to build the menu and do all the prefs stuff in JS (in editor.js). The only way I know to get to JS from C++ is via a command.

I'd also prefer to see the recent menu supported only in the JS files (no references to it in C++). Can the menu listen for title changes?

re: listening for title changed: I don't think we can do that.

After testing this on Mac, I don't think we should rebuild the recent menu after the title has been changed. The problem is that the user might change the title but then not save the file so the "recent" menu will reflect the wrong title. It seems like updating the recent menu on save (html) or open should be sufficient.

Does this patch put exported text files on the recent menu? I don't think they should appeear there.

no, the recent menu only shows html files

Ready to check in. Changed wording according to sfraser: menu item will be "Export to Text..." Re: brade's observation about changing recent menu: The recent menu will not be updated and saved to prefs if only the title changes; it will be saved when file is opened or saved.

Separate menu item for "Export to Text..." implemented.

suzanne, is this working for you now ?

wfm

marking verified.

I still see html tags getting saved when selecting option to save as text in IM messages, but in Compose, "exporting to text" works ok... should the IM bug go to Bugscape? See this on Win32 2001-04-19-06Mtrunk build

Suzanne--if you are still seeing this problem in AIM, you should file a bug in bugscape (if you haven't already).

yeah, we have a bug in Bugscape - 4649. Thanks for pinging me anyhoo :-)

er, thats bugscape 4694 (sorry for the spam!)