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)

x86
Linux
defect
Not set
major

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.
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.
> 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.
> 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.
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
Assignee: benjamin → nobody
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
Component: Startup and Profile System → Migration
QA Contact: benjamin → migration
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?
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...
Flags: blocking1.8b4? → blocking1.8b4-
Not a core issue in any case, so shouldn't be blocking 1.8anything.
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.5? → blocking-aviary1.5-
Summary: Download manager window/auto-handling settings not correctly migrated from Seamonkey → Download manager window/auto-handling settings not correctly migrated from SeaMonkey
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.