User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5 When I link to the specified URL or Enter it, Firefox does nothing but downloads a .part file. It should open the file with the handler registered for text/calendar, which is the correctly provided mime-type in the url. Reproducible: Always Steps to Reproduce: 1. copy'n' paste url Actual Results: Firefox downloads the file, doesn't rename the .part file and doesn't open the default-application. Expected Results: Firefox should download the file, rename it correctly (remove the .part suffix) and open it using the registered default application.

I can reproduce this specific case (latest 3.1 on Linux), however when asking where to save the file its suggested name is already <random>.ics.part. If I just change the name I can save it normally.

I just found that my firefox correctly recognizes the file as "ICS-File". When I set the handler for ICS-Files to download the file, I get the download-dialog. When I set it to use ICal, the file is downloaded correctly, but nothing happens.

Is there some workaround for this?

This doesn't only happen for data URI's. Also "Save Link as..." is affected by this bug. This regressed somewhere on the 1.9.0 branch. FF2.0.0.20 works fine. We need a regression range here.

This regressed between the following builds: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040204 Minefield/3.0pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040304 Minefield/3.0pre Checkins: http://tinyurl.com/cye8lc As what I can see bug 299372 has been caused this problem. Putting Justin on the CC list due to he has written the patch.

Further steps are: 1. Load http://www.mozilla.org/projects/firefox/3.0pre/whatsnew/ 2. Open the context menu of the Mozilla logo 3. Click on the "Save link as..." menu item

It looks like the old codepath [going through saveURL() / getDefaultFilename() in contentAreaUtils.js] can determine the filename differently than the new codepath [going through DoContent() / GetFilenameAndExtensionFromChannel() in nsExternalHelperAppService.cpp]. GFAEFC() basically just uses nsIURL.fileName, and if that's empty it gives up (which presumably results in some other code creating a randomized filename?). getDefaultFilename, OTOH, has a series of fallbacks for the filename: document title, last directory name, hostname, or even just "index". This bug should manifest when saving any link that doesn't have a filename in the URL (data:foo, http://foo/, http://foo/bar/, etc.). Note that we fall back to the old code path when the browser.download.saveLinkAsFilenameTimeout fires, so if the server is slow you might see this work correctly. [And, as a potential workaround, you could set this pref 0, though that basically causes bug 299372 again.] So, we either need to make the caller smarter about providing a default file name to the nsExternalHelperAppService bits, or make nsExternalHelperAppService better at picking fallback filenames.

I just ran into this when someone emailed me a text/calendar link: http://www.meetup.com/The-South-Bay-Electronic-Music-Meetup-Group/calendar/ical/The+South+Bay+Electronic+Music+Meetup+Group/

See also bug 367231.

Confirming still present in Firefox 3.5.8 on Mac OS X 10.5.8. The workaround is to do a Save As and then manually remove the .part from the filename. I encountered this when trying to download the "Business Edition Datasheet" from this page: http://pbworks.com/?srcWiki=pbworksweb7&apikey=3a218cad18647dd2dd338f5bc7d8b6ff22a63207&p=generic&w=biz+resources

Still present on v.19 in Mac OS X 10.8.2

After loading data:text/calendar;charset=utf-8,BEGIN%3AVCALENDAR%0AVERSION%3A2.0%0AMETHOD%3APUBLISH%0ABEGIN%3AVEVENT%0ADTSTART%3A20090306T143000%0ADTEND%3A20090306T163000%0ASUMMARY%3APr%C3%BCfung%3A Algorithmen und Datenstrukturen 2%0ALOCATION%3AAudi. Max.%2C GM 1%0AURL%3Ahttp%3A%2F%2Fwww.wegweiser.ac.at%2Ftuwien%2Fhoersaal%2FAUDI.html%0ADESCRIPTION%3A%0AEinzel%0A(E186 Pr%C3%BCfung)%0AUID%3Atu-exam-186.170-20090306%0ASEQUENCE%3A0%0ADTSTAMP%3A20090023T155211Z%0AEND%3AVEVENT%0AEND%3AVCALENDAR in Firefox 19 beta 4 (build ID: 20130130080006) on a Mac OSX 10.8 machine I get the following: 1) If I want to open the file, it's opened with the CalendarFileHandler application, as expected 2) On the other hand, if I want to save the file, this is saved with .ics(1).part or .ics-1.part extensions. But when I try to open the file and select the Calendar application to open it, the file is opened as expected.

I get the same results as in comment 16, with the link from comment 9: http://www.meetup.com/The-South-Bay-Electronic-Music-Meetup-Group/calendar/ical/The+South+Bay+Electronic+Music+Meetup+Group/

Please note that a workaround is available in v20. By specifying the "download" attribute I was able to get a correct file download in both Windows and Mac on Aurora 20.

Cannot reproduce with steps from comment 16 or comment 9 when using Nightly v23.0a1

Closing based on Comment 19 Please provide Firefox Version and updated STR if this should be reopened.