Last Comment Bug 528777 - Save on HDD does not work from context menu
: Save on HDD does not work from context menu
Status: VERIFIED FIXED
: fixed-seamonkey2.0.3
Product: SeaMonkey
Classification: Client Software
Component: Download & File Handling (show other bugs)
: SeaMonkey 2.0 Branch
: All All
: -- normal (vote)
: ---
Assigned To: neil@parkwaycc.co.uk
:
:
Mentors:
http://www.shlomifish.org/Files/files...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-15 00:18 PST by Rainer Bielefeld
Modified: 2009-12-16 11:23 PST (History)
5 users (show)
kairo: blocking‑seamonkey2.0.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Display in Download Manager (86.65 KB, image/jpeg)
2009-11-23 01:58 PST, lenochod
no flags Details
Proposed patch (686 bytes, patch)
2009-12-01 08:30 PST, neil@parkwaycc.co.uk
iann_bugzilla: review+
iann_bugzilla: approval‑seamonkey2.0.3+
Details | Diff | Splinter Review

Description Rainer Bielefeld 2009-11-15 00:18:51 PST
Since I ubgraded from 1.8.x to 2.0, I see foolllowing problem:

Steps to reproduce (please notice that I use" Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0", menu items names translated from German language):
1. click a.m. URL
2. click on "cmake-tutorial.odp"
   expected: "open" dialog opens with seleciton 'open with' or 'save file'
3. selelect 'save file'
4. <ok>
  as expected: file picker dialogue opens
5. select folder and file name, save
   as expected, document will be saved without problems

now try again with context menu:
11. click a.m. URL
12. right click on "cmake-tutorial.odp"
13. slelect 'save link' from context menu
    as expected: file picker dialogue opens
14. do not select new  folder, modify file name to "cmake-tutorial.odp", <save>
    expected: file will be saved
    actual: nothing, download manager will show endless save activity 
            without any progress

This is a general problem, not only for example document "cmake-tutorial.odp"
Comment 1 Matthias Versen [:Matti] 2009-11-15 02:52:26 PST
seems to work with SM trunk on vista
Comment 2 Rainer Bielefeld 2009-11-19 22:00:50 PST
A.m. URL seems to be not a good example (the only URL  that works ...)
I see that with any other URL I try. For example, go to 
<http://www.openoffice.org/issues/show_bug.cgi?id=107062> and try to download Attachment "issue.ods" using right click.

Or
Go to <http://www.seamonkey.at/download/>
Right click "Windows Standard Download" under "Binaries (Gepackte ausführbare Versionen)"
Comment 3 lenochod 2009-11-20 03:17:29 PST
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091118 SeaMonkey/2.1a1pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6pre) Gecko/20091118 SeaMonkey/2.0.1pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0

Win XP SP3 - I confirm this bug.

When I right-click on the link and I will select Save Link Target As,
item display in the download manager but it is not downloaded and stored on disk.
Comment 4 Matthias Versen [:Matti] 2009-11-20 05:56:23 PST
is browser.download.lastDir pointing to a valid Directory in your profile ?
Did you try a new profile ?
Comment 5 lenochod 2009-11-23 01:58:13 PST
Created attachment 414008 [details]
Display in Download Manager

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6pre) Gecko/20091118 SeaMonkey/2.0.1pre

Still bad behavior in the new profile. 
browser.download.lastDir - path is OK.
Comment 6 Rainer Bielefeld 2009-11-23 05:19:26 PST
@Matthias "matti" Versen:
No Idea where 'browser.download.lastDir' points and where I should check that. But after right click I select manually the directory where the linked file should be saved, so that directoriy definitively is valid.
Comment 7 Rainer Bielefeld 2009-11-23 05:27:52 PST
And modifying Profile does not help here, too. 

No Idea why some links work and others do not. Try link 
"Kundendienst-Preisliste" on 
<http://www.bielefeldundbuss.de/service/service.html>
That one will work.
Comment 8 lenochod 2009-11-23 06:33:49 PST
Write about:config into the URL bar and hit Enter.
Type "browser.download.lastDir" (without the quotes) into the Filter box
Comment 9 Robert Kaiser 2009-11-30 12:27:45 PST
(In reply to comment #2)
> A.m. URL seems to be not a good example (the only URL  that works ...)
> I see that with any other URL I try. For example, go to 
> <http://www.openoffice.org/issues/show_bug.cgi?id=107062> and try to download
> Attachment "issue.ods" using right click.

Works for me on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091130 Lightning/1.0b1pre SeaMonkey/2.0.1pre

> Or
> Go to <http://www.seamonkey.at/download/>
> Right click "Windows Standard Download" under "Binaries (Gepackte ausführbare
> Versionen)"

Also works for me here.


One possible "issue" is that it might only work if the reply from the server is fast enough, as else we'd block the download without any notification for an indefinite time, which we don't want to happen - it's better to miss the file name in cases that take longer.
Comment 10 Rainer Bielefeld 2009-11-30 23:26:15 PST
Fine for you! seamonkey download today works for me, OOo does not. 

Your idea with "server reply time" does not satisfy me, why should that (always) work with left click, but not from context menu?
Comment 11 Robert Kaiser 2009-12-01 06:42:35 PST
It's indeed strange, I'm just grasping for any explantation or such, as I don't know the code. Maybe Neil knows more.
Comment 12 neil@parkwaycc.co.uk 2009-12-01 08:30:50 PST
Created attachment 415400 [details] [diff] [review]
Proposed patch

What used to happen:
1. Left-click: waits for server reply. If it's something we can't display, pop up a save/open with dialog instead. URL is based on server reply.
2. Right-click: immediately downloads to filename based on link URL
However bug 427642 was ported from Firefox whereby if the server replies quickly enough then the URL is still based on the server reply.
Unfortunately the Firefox version of saveURL has an aSkipPrompt flag (which confusingly is false if you want to force a prompt and true if you want to allow a prompt as per user preferences) which we currently don't support.
Comment 13 :Hb 2009-12-04 12:37:22 PST
*** Bug 532866 has been marked as a duplicate of this bug. ***
Comment 14 neil@parkwaycc.co.uk 2009-12-08 15:46:08 PST
Pushed changeset 70338c4e8c39 to comm-central.

Pushed changeset 531d82154a90 to releases/comm-1.9.1
Comment 15 Robert Kaiser 2009-12-09 07:27:53 PST
Not blocking the 2.0.1 security update on this, and already fixed for the next one :)
Comment 16 lenochod 2009-12-10 03:21:33 PST
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7pre) Gecko/20091210 SeaMonkey/2.0.2pre

FIXED->VERIFIED

Note You need to log in before you can comment on or make changes to this bug.