109790 - Request ability to save contents of windows

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, enhancement)

Description

[Albert Croft]

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.

Comment 1

[Tim Powell]

Might I suggest the obvious: File->Save As?

All/All because I see this with Mozilla 2002020208 on Win2K

Comment 2

[Samuel Sieb]

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

Comment 3

[Tim Powell]

>>> 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.

Comment 4

[Aleksander Hropot]

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.

Comment 5

[Garth Wallace]

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.

Comment 6

[James Ross]

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.

Comment 7

[Samuel Sieb]

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.

Comment 8

[:Gijs (he/him)]

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.

Comment 9

[:Gijs (he/him)]

Attachment: First patch to save contents of view

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.

Comment 10

[:Gijs (he/him)]

Attachment: Improved patch, got rid of the warnings.

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 11

[Samuel Sieb]

Comment on attachment 173682 [details] [diff] [review]
Improved patch, got rid of the warnings.

r+ with minor changes as discussed on irc

Comment 12

[:Gijs (he/him)]

Attachment: Patch with minor changes as discussed on IRC :-)

New better patch based on the minor changes requested.

Comment 13

[:Gijs (he/him)]

Attachment: Patch which fixes the title being appended multiple times when you save multiple times

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.

Comment 14

[:Gijs (he/him)]

Attachment: Patch removes original title

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

Comment 15

[:Gijs (he/him)]

(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 16

[James Ross]

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. :)

Comment 17

[:Gijs (he/him)]

Attachment: Fixes QI

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

Comment 18

[James Ross]

Comment on attachment 175662 [details] [diff] [review]
Fixes QI

review=[e-mail]

Does what I asked. We will see if this causes any problems for the 1 or 2
people who use custom output windows. :)

Comment 19

[James Ross]

Checked in --> FIXED.

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

Comment 20

[Ian Neal]

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

Comment 21

[:Gijs (he/him)]

(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?

Comment 22

[Ian Neal]

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.

Comment 23

[James Ross]

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).