Using 2001-10-31-03-trunk commercial builds. This is similar to bug 82583 rather than to bug 107314 as I don't think this feature was ever implemented for newsgroups. If you download a newsgroup message with an attachment (i tried a jpeg and text attachments), go offline, and try to save the attachment it results in a error message: "Uable to save the attachment. Please check your file name and try again later." Double clicking attachment (other than attach that can be opened up in the browser) results in no dialog window popping up asking you if you want to open or save that file.

This works fine if online. Only when offline does it not work.

I've noticed this up to & including 0.9.5. Note that the 'index' gets updated correctly: goes dark grey, has small paperclip icon. Also note that the download *has* occurred, and the downloads are sitting in the newsrc dir. under a file named after the n/g. You can cut it up & uudecode it by hand(!) Moz just won't access the attachment bit.

yeah, it fails trying to get the uri, and tries to make an nntp connection when it shouldn't.

the problem is that we haven't discovered that the msg is in the local cache when imglib is running the url to fetch the part, so we bail out and try to make a new connection. So we need to make sure we discover if the message is in the local cache for this case.

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

I found this problem. My first attempt at a work around was to view the message source and extract the attachment from the source. However you can't view the message source either. Bug 128297. "news: source not available while reading messages offline" I've added a note about this bug to bug 128297. Should there me a dependancy between the two bugs ?

the bugs are related - they might be the same bug, or they might have the same fix in two places, but they're not dependent (which means you have to fix one to fix the other).

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

Further info. - due to bug 14508 (which prevents context-menu saving from the body of a message [dialogue doesn't appear]), the only way to save attachmanets/images is the contxt menu off the attachment list (top-right). Even when *online*, this doesn't seem to want to use any cached version of the attachment (i.e., you wait for the attachment to download, then have to wait again after a save-as). It used to be (pre 0.9.7?) that these things were cached and were saved instantaneously. Basically just pointing out: it's not just an offline thing.

Sorry - meant to ref. bug 145408.

nominating..

Discussed in mail news bug meeting. Decided to minus this bug.

The basic reason none of these things work offline is that news runs urls of the form news://host/message_id instead of news-message://host/group#key to fetch messages. Unfortunately, we store the offline news messages in different files per newsgroup (which helps keep the offline stores from getting too large), as well as the fact that we have an offline copy of a msg in the newsgroup's db file. So, when we see news:/host/message_id?partnum=1&filename="foo.jpg", we have no way of knowing that we have the message offline, and we have to fail. I know there was a reason that Seth converted our urls to be the message_id form (it might have to do with printing), but it really breaks a lot of the offline stuff. The only way I can think of fixing this is to add a little hash table to the news server object that maps between message_id's and group+msg keys, so that when we have the former, we can find the latter. Whenever a message gets loaded by message_id, we'd add an entry to the hash table. If the user then tries to save an attachment, we'd convert the message_id to the correct group and msg key, and be able to know if we have the msg offline. In theory, we'd really only need one of these entries, since the user is most likely acting on the message they're displaying, but you can have multiple messages in a newsgroup open at the same time, so we need to keep track of multiple mappings.

If you want to work offline with a notebook in a train it isn't possible to get protocols or other attached stuff. IMHO it is a really ugly bug and should be fixed asap -> P1. Also it happens on ALL platforms.

clearing keyword nsbeta1- and renominating

Mail triage team: nsbeta1-

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040316] (W98SE) (In reply to comment #13) > The basic reason none of these things work offline is that news runs urls of the > form news://host/message_id instead of news-message://host/group#key to fetch > messages. > I know there was a reason that Seth converted our urls to be the message_id form > (it might have to do with printing), but it really breaks a lot of the offline > stuff. Updating: *(S) normal -> major > The only way I can think of fixing this is to add a little hash table to > the news server object that maps between message_id's and group+msg keys, so > that when we have the former, we can find the latter. '(T.M.) mozilla1.2alpha' was missed :-( Any hope for v1.8a ?

Does anyone know if this is working in ThunderBird ?

this is a backend problem, so it will be in both seamonkey and tbird.

Just want to confirm that this still happens in 1.7. We are having complaints from users on this and this definitely needs to be fixed before the next release (1.8 final). I would nominate this as a blocker for 1.8, a) because it is a very old problem (from 2001, milestone was 1.2alpha) and b) because offline functionality is definitely broken if news messages which have been synchronized for offline use are not "complete".

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b3) Gecko/20050714 SeaMonkey/1.0a] (nightly) (W98SE) (Bug still there) Moving from MailNews to Core component, per comment 19.

[Netscape® Communicator 4.8 : en-20020722] (W98SE) Works fine.

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

Offline news gets no love... but recognition!

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.1pre) Gecko/2008061902 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) Bug still there. If this can't be fixed "soon", maybe the "Save" feature should be disabled for such cases in the meantime ?

(In reply to comment #25) I think this error did not use to be there, did it ? {{ Error: uncaught exception: [Exception... "Component returned failure code: 0x80550014 [nsIMessenger.saveAttachment]" nsresult: "0x80550014 (<unknown>)" location: "JS frame :: chrome://messenger/content/msgHdrViewOverlay.js :: saveAttachment :: line 1055" data: no] }}

Triaging according to new policy for flags. https://wiki.mozilla.org/Thunderbird:Release_Driving Not a primary focus for the thunderbird3 release; wanted- does not indicate we wouldn't accept patches.

In this patch, what I do is introduce a universal canonicalization for the cache key: namely, use the message ID if possible, get the message ID from the header if it exists, otherwise use group/key, otherwise it's not cacheable (only articles can be cached). With this patch, I can indeed get a useful file if I save an attachment.

Oh, I neglected to mention: this requires at least part 6 of bug 226890 to apply correctly and probably at least part 7 to work correctly. Apply all parts for best results.

Comment on attachment 503252 [details] [diff] [review] Universally canonicalize the cache key This patch doesn't seem to make any difference w.r.t. saving attachments offline, unfortunately. I have all your patches applied, afaict. Also, I don't see how this helps with offline store, as opposed to the disk cache (this seems to be affecting the disk cache, though even that didn't seem to help)

Comment on attachment 503252 [details] [diff] [review] Universally canonicalize the cache key Cancelling sr request for now due to the r-.

> Also, I don't see how this helps with offline store, as opposed to the disk > cache (this seems to be affecting the disk cache, though even that didn't > seem to help) On closer review, I think I see why this didn't work. I had originally intended this patch to be the base for newsuri-deoriginal, which would have eliminated the rewriting of the message URIs. However, deoriginal got greedy and caused regressions, so I backed it out of my tree. Let's see if I can get this fixed for real, then.