Closed
Bug 264702
Opened 20 years ago
Closed 13 years ago
Download manager window/auto-handling settings not correctly migrated from SeaMonkey
Categories
(Firefox :: Migration, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: bzbarsky, Unassigned)
Details
BUILD: Nightly downloaded from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-10-16-09-0.9/firefox-1.0.en-US.linux-i686.tar.gz STEPS TO REPRODUCE: 1) Make sure there is no .mozilla/firefox directory 2) Launch Firefox 3) Migrate the Mozilla profile 4) Load https://bugzilla.mozilla.org/attachment.cgi?id=161578&action=view EXPECTED RESULTS: Browser asks you what to do with the file ACTUAL RESULTS: The file is silently saved to $HOME, download manager never appears. NOTES: Checking the preferences settings, they are set to "Save all files to this desktop" (which explains the automatic saving to $HOME, sorta), and "Show download manager when download begins". "Close download manager when download is complete" is NOT checked. My Mozilla profile uses progress dialogs, not the download manager, and has "close on download complete" set. I would have expected this behavior to be migrated, but also to be prompted for each download. Note that a brand-new profile created by Firefox itself (not via migration) prompts for every download. Marking this major, since I couldn't figure out why Firefox wasn't offering to save my zip file.
| Reporter | ||
Comment 1•20 years ago
|
||
Oh, so there are two issues here: 1) The download manager does not appear though the settings say it should 2) Firefox doesn't prompt for the location.
Flags: blocking-aviary1.0?
I was under the impression that Firefox does not prompt for the saving location by default (Personally, I always want it to prompt, but my understanding is that this was done for average users who just save everything to the desktop in the first place). The window not closing is also a default, although migration probably should pick it up. The reason that the download manager never appeared might be from the fact that the download window will not appear when you are downloading very small files - many users complained about how annoying it is when the download manger appeared and quickly closed when downloading image files from cache.
| Reporter | ||
Comment 3•20 years ago
|
||
> I was under the impression that Firefox does not prompt for the saving > location by default That may be the intent, but in my test it did prompt. > the download window will not appear when you are downloading very small files That's possible (though this file was about 65K, and was NOT cached locally, this being a brand-new profile). But the point remains that I got absolutely no feedback that the file had been saved, no indication where it had been saved to, and no indication what it was named. Now I'm luckier than most in that I know the overall structure of the Firefox file handling code, so I could guess where it stuck the file and what it named it. But in general, I'd fully expect a user to be very confused by this behavior.
I just created a new profile and the default for me is to automatically download to the desktop. I still get a prompt for saving the file, but not the filepicker prompt (this is expected). The only way I can reproduce the bug is if: 1) Saving to desktop is set (default) 2) Saving of zips is the default action (this prevents the saving prompt) 3) I have a really fast connection (to not trigger the download progress window) So, I agree something is messed up.
| Reporter | ||
Comment 5•20 years ago
|
||
> I still get a prompt for saving the file, but not the filepicker prompt (this
> is expected).
Right. I'm getting neither prompt--the file is just being saved completely
silently.
Now in my Mozilla preferences I do have zip files set as "save to disk", but I
also have it set to prompt (which Mozilla does). Migrating one preference but
not the other (which may be happening here) would be wrong.
I have a standard DSL connection; nothing magic there.(In reply to comment #5) > Now in my Mozilla preferences I do have zip files set as "save to disk", but I > also have it set to prompt (which Mozilla does). Migrating one preference but > not the other (which may be happening here) would be wrong. That is probably the problem and I am not sure of the best way to deal with it. One approach is if we import file actions we should default to prompt for download location. The other alternative, if we want to keep automatic downloading on for all new users, would be to not import file actions at all (see Bug 264265) - which would present a mild annoyance to new users.
Updated•20 years ago
|
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Summary: Download manager busted in migrated profiles → Download manager window/auto-handling settings not correctly migrated from Seamonkey
Updated•20 years ago
|
Assignee: benjamin → nobody
| Reporter | ||
Comment 7•20 years ago
|
||
Please just don't import the preference at all if it can't be imported correctly... that can't be that hard, can it? (I know, famous last words.) As things stand, migrating to Firefox from Suite (which we are encouraging, last I checked) is rather annoying due to this bug...
Flags: blocking-aviary1.1?
Version: 1.0 Branch → Trunk
Updated•19 years ago
|
Component: Startup and Profile System → Migration
QA Contact: benjamin → migration
Comment 8•19 years ago
|
||
If we're not showing the download manager at all, that's a bug. Always defaulting to the automatic download is a design decision. There isn't an equivalent in seamonkey so its not something to migrate, so it seems that you're arguing that if we import from Seamonkey, we should have a different default. Bumping to b4 list for further review.
Flags: blocking-aviary1.1? → blocking1.8b4?
| Reporter | ||
Comment 9•19 years ago
|
||
I'm arguing that either you want to use a different default based on the exact values of the SeaMonkey prefs (set new default as part of migration process?) or you need to not migrate the relevant SeaMonkey prefs...
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4-
| Reporter | ||
Comment 10•19 years ago
|
||
Not a core issue in any case, so shouldn't be blocking 1.8anything.
Flags: blocking-aviary1.1?
Updated•19 years ago
|
Flags: blocking-aviary1.5? → blocking-aviary1.5-
Updated•18 years ago
|
Summary: Download manager window/auto-handling settings not correctly migrated from Seamonkey → Download manager window/auto-handling settings not correctly migrated from SeaMonkey
Comment 11•13 years ago
|
||
Closing this bug since Seamonkey migration was removed in bug 679016.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•