From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 BuildID: 2001101201 There does not appear to be an option to allow for saving the contents of a conversation window. Reproducible: Always Steps to Reproduce: 1.Open chatzilla session 2.Determine window contains content you wish to save 3.Look for way to save short of copy-paste to another editor Actual Results: There appears to be no way save the contents of a window/panel. Expected Results: An option (either in menu or mouse-click or key combination) to allow to save contents of a panel.

Might I suggest the obvious: File->Save As? All/All because I see this with Mozilla 2002020208 on Win2K

Where is this obvious File->Save As? This is a bug filed against chatzilla, not the browser.

>>> An option (either in menu or mouse-click or key combination) >>> to allow to save contents of a panel >> Might I suggest the obvious: File->Save As > Where is this obvious File->Save As? Sorry for not being clearer. I was simply suggesting adding a menu item of File- >Save As. I miss this in chatzilla, too. While we're at it, Ctrl+S is the typical save keystroke. Chatzilla currently has it mapped to toggling the status bar, but I wouldn't think those need keyboard shortcuts.

the easiest solution would be implementation of LOG (on|off) and LASTLOG (number of lines > file.txt) commands, like all irc clients do. may i remind you IRC still runs on the CLI like interface, pupups, menu items and other fancy schmancy stuff are just a cover. logging of windows (channels, private messages) should be made an user preference.

Logging should certainly be a preference. OT: I disagree that IRC "works on a CLI interface". A client that implements all commands past sending plain text through a GUI (rather than /commands) would be a perfectly legitimate IRC client. Not that I'm suggesting that Chatzilla do that.

ChatZilla now has logging support, though we lack a UI for (or any way to know about) the prefs for default logging state for client/network/channel/user tabs.

This is not about logging, this is about saving the *current* contents of the view. Although comment #4 suggests including it in the logging functions, which is a good idea. Start logging and save /n/ previous lines as well. But sometimes you just want to save the current contents without starting logging.

taking. I'll try and add a /save [<filename>] command, as well as a menu item with a dialog (and obviously, using save without <filename> would bring up the dialog as well). I suppose I could also try for a save-all command, if anyone would like that.

Right, took me a while, but here it is. Has a save dialog, /save command. Also changes some stuff in utils.js to make the file picker a bit more customizable. Will try to deduce the saving type from the url or local path given to /save, or use a specific type if specified.

Of late, I noticed my patch threw warnings to the js console about some of the syntax used. It was nothing that prevented it from working, but I wanted to get rid of it, so here's a new patch.

Comment on attachment 173682 [details] [diff] [review] Improved patch, got rid of the warnings. r+ with minor changes as discussed on irc

New better patch based on the minor changes requested.

Fixes a small error of the previous patches which caused the title for the document to be added again even if it was already there due to the fact the view had been saved before.

Removing the original title when you save twice, or you'll end up with a giant list of them ;-).

(In reply to comment #14) > Created an attachment (id=175185) [edit] > Patch removes original title > > Removing the original title when you save twice, or you'll end up with a giant > list of them ;-). Scrap that. What I meant was that in the previous patch, the timestamp in the title would never change. It does now, since now the original is removed instead of the new one not being added.

Comment on attachment 175185 [details] [diff] [review] Patch removes original title This is not a formal review as such, but I am going to makr review- because of the big problem I found while scanning the code. >+ QueryInterface: function(aIID) >+ { >+ if (aIID.equals(Components.interfaces.nsIWebProgressListener) >+ || aIID.equals(Components.interfaces.nsISupports) >+ || aIID.equals(Components.interfaces.nsISupportsWeakReference) >+ || aIID.equals(Components.interfaces.nsIPrompt) >+ || aIID.equals(Components.interfaces.nsIAuthPrompt)) >+ { >+ return this; >+ } >+ >+ throw Components.results.NS_NOINTERFACE; >+ } Your object can be QueryInterface'ed to 5 different interfaces, but two of them are not actually supported by your object! Neither nsIPrompt's nor nsIAuthPrompt's methods are there. Either their methods should be on the object, or you should fail attempts to QI to them. (Lucky for you that XPConnect doesn't 'care' until someone does try the QI, but believe me, if they tried it would throw a wobbly.) >+ var wbp = newObject("@mozilla.org/embedding/browser/nsWebBrowserPersist;1", >+ nsIWBP); The second parameter could be "nsIWebProgressListener" instead if you like, but I see you've used this interface lower-down so that's ok. :)

Fixed by removing the two offending entries from the condition, as advised by Silver on IRC.

Comment on attachment 175662 [details] [diff] [review] Fixes QI review=silver@warwickcompsoc.co.uk Does what I asked. We will see if this causes any problems for the 1 or 2 people who use custom output windows. :)

Checked in --> FIXED. In approximately 42 minutes a build with this fix will be available from: http://twpol.dyndns.org/mozilla/chatzilla/nightly/

Does this patch take account of the browser.download.autoDownload pref?

(In reply to comment #20) > Does this patch take account of the browser.download.autoDownload pref? No - since I have no idea what it is. Sorry :-(. Could you please explain what this preference is about and why it is relevant? This bug is about saving messages from a channel view - so you're not downloading anything, unless specified in the html file used for your output window (ie, flash, css, image files), which means you are already using it. I could not find this preference in about:config on FF 1.0 or Suite 1.7.3, and all mentions I could find about it on Google were about Camino / Chimera. Which is not what ChatZilla is made for. In short, could you please explain what you expect it to do / take account of?

If browser.download.autoDownload is set to true then mozilla does not prompt you for a location to download/save information to (it came in during 1.8a cycle). Firefox does something similar but using a different pref.

I think the best option is to open a new bug to add the following: - Utility function to check if the host app is in "no prompt" mode. - Utility function to get a nsIFile/nsILocalFile for the auto-save location. - Changes to the DCC and this Save As code to use the above two. The hard bit is likely the first two, hence I would rather they were dealt with on a separate bug (since this one is technically fixed now).