linux firefox trunk 2007-10-13-19Z Downloading /tmp-1 /!\ /tmp-1 could not be saved, because you cannot change the contents of that folder. Change the folder properties and try again, or try saving in a different location. [OK] case one: at https://bugs.maemo.org/show_bug.cgi?id=693#c7 middle click attachment case two: at http://tablets-dev.nokia.com/d2.php left click on rootstrap_..._v2.2 (it probably wants you to click a button or such to set a cookie first) not readily reproducible.
I've seen this a couple of times too in the last few days. Usually trying to download the file again fixes the problem when it occurs. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007101704 Minefield/3.0a9pre
I see this, too. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007102004 Minefield/3.0a9pre
I'm having trouble reproducing this. The steps to reproduce here are pretty vague. Can you post in fairly explicit detail exactly the list of actions / clicks that leads to this error? In particular, I'm trying to understand if/how the filepicker is involved here.
I can usually reproduce it by setting "Always ask where to save files", then initiating several downloads in sequence. Usually, the 2nd or 3rd simultaneous download will result in the /tmp-1 error instead of the file picker.
Blocking for investigation ... can someone figure out what's causing this, please?
(In reply to comment #6) > This should be fixed by bug 402298. I tried to download files many times but I can't reproduce with today's build. I think this is fixed too.
-> Fixed per comment #7. If there's a general download litmus testcase per platform, this could work well for linux as on other platforms, the parent of the temp directory is generally user writable. "download a bunch of open-with files" (On linux, does the error show up right away during/before the open-with dialog? That could simplify testing if the user can just start and cancel downloads instead of waiting for them to finish.)
My brother Jeff emailed me a few days ago, telling me he experienced this bug on a daily basis, and that the recent nightlies (running under Ubuntu Linux) have indeed fixed this. My own testing--and others--confirms this to be true, using: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007110604 Minefield/3.0a9pre Verified FIXED