299882 - Downloads > Download Folder directory is not updated

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect, P2)

Description

[Sylvain Pasche]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050706 Firefox/1.0+

On linux (ok on windows last time I checked), the directory in the "save all
files to this folder" textfield is not updated correctly.

Reproducible: Always

Steps to Reproduce:
1. Go to Deer Park Preferences > Downloads
2. Choose "save all files to this folder", and click "Browse.."
3. Select a random folder and press "Open"
4. The selected folder is shown in the list
5. Now, click once again "Browse.." and choose another folder

Actual Results:  
The textfield is not updated with the new folder, but keeps the old one (that's
just the display, because if you close and reopen the preferences, it shows the
new one).

Expected Results:  
The folder directory should have been updated

See the last comments on bug 283608

Comment 1

[Adam Guthrie]

*** This bug has been marked as a duplicate of 284089 ***

Comment 2

[Sylvain Pasche]

Sorry, this is not a duplicate of 284089. The simple proof is that this bug is
still there with today's nightly build, although patch for bug 284089 has been
commited since 2005-06-30.

Comment 3

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050716 Firefox/1.0+
ID:2005071622

Oops. I can confirm this too.

Comment 4

[Anbo Motohiko]

Attachment: patch

On windows, set browser.preferences.instantApply to true to see this problem.

The textfield of download destination folder is only updated when
browser.download.folderList is changed. The textfield should see
browser.download.dir.

Comment 5

[Bob Peers]

Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3)
Gecko/20050712 Firefox/1.0+

I have the same problem but also note that the path cannot be manually edited or
even selected, forcing me to use the browse button which doesn't work.

Comment 6

[Adam Guthrie]

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

Comment 7

[Erwin Harte]

For what it's worth, I can confirm seeing this behaviour in "1.5b1":

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908
Firefox/1.4

The browse button does work for me, but you won't actually -see- the change
until you exit the preference popup and revisit it.

Comment 8

[Deb Richardson [:dria] (plz NEEDINFO)]

I just confirmed this behaviour in 1.5b2.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006
Firefox/1.4.1

The selected folder does not change in dialog until Preferences dialog is exited
and reopened.

Comment 9

[Adam Guthrie]

Attachment: patch (non-bitrotted)

Comment 10

[Asaf Romano (gone)]

Comment on attachment 198871 [details] [diff] [review]
patch (non-bitrotted)

add "return undefined;" to writeFolderList instead.

Comment 11

[Adam Guthrie]

Attachment: patch v2.0

There's no point in calling that function if we're always going to return
undefined. This patch also fixes /mail's download.xul.

Comment 12

[Asaf Romano (gone)]

Comment on attachment 198891 [details] [diff] [review]
patch v2.0

Eh? This will break the special casing of the "Dekstop" folder, etc.

Comment 13

[Asaf Romano (gone)]

Attachment: something for now

We may want to optimize it at some point, so we never run through
readDownloadDirPref twice.

Comment 14

[Asaf Romano (gone)]

Checking in downloads.xul;
/cvsroot/mozilla/browser/components/preferences/downloads.xul,v  <--  downloads.xul
new revision: 1.10; previous revision: 1.9
done

Comment 15

[Asaf Romano (gone)]

1.8 branch:
Checking in browser/components/preferences/downloads.xul;
/cvsroot/mozilla/browser/components/preferences/downloads.xul,v  <--  downloads.xul
new revision: 1.8.2.1; previous revision: 1.8
done