Cannot open text files in external application
Categories
(Firefox :: File Handling, defect)
Tracking
()
People
(Reporter: ebs15242, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Steps to reproduce:
Create new profile. Visit
https://blast.ncbi.nlm.nih.gov/Blast.cgi?PROGRAM=blastn&PAGE_TYPE=BlastSearch&LINK_LOC=blasthome
BLAST a sequence, e.g. "AAACCCATTCAGGAAGTGCTAAAGGAAATGACTGATGGAGGTGTGGATTTTTCGTTTGAA"
Click an alignment, select the Download drop down on the upper left, select Text (aligned sequences) and Continue.
Open With->Browse->Browse->Navigate to 'C:\Program Files (x86)\Vim\vim80', select gvim.exe
Select "Do this automatically", then OK.
Close gvim, and select Download->Text(aligned sequences) again.
Go to Options->Applications and inspect associations.
Actual results:
gvim opened the first time, but did not open automatically the second.
TXT file is listed in under "Applications" with "Use Vi Improved" as the option
Expected results:
gvim should open every time I click a text file.
Oddly, other sources of text files (e.g. https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt) do not prompt a file open dialog and open in Firefox automatically. In a fresh profile, there is no entry under Options->Applications for text files and apparently no way to change this behavior.
Comment 2•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 3•5 years ago
|
||
This looks related:
I haven't figured out if we're hitting this, and why (and why not always), but it does seem that saving to disk as a saved action does work here. I'll try and find time to look into this in more detail next week.
Comment 4•5 years ago
|
||
Apparently this is intentional... The comment at the code linked in comment #3 refers to earlier code, which has this comment:
// We can get here for three reasons: "can't handle", "sniffed type", or
// "server sent content-disposition:attachment". In the first case we want
// to honor the user's "always ask" pref; in the other two cases we want to
// honor it only if the default action is "save". Opening attachments in
// helper apps by default breaks some websites (especially if the attachment
// is one part of a multipart document). Opening sniffed content in helper
// apps by default introduces security holes that we'd rather not have.
In this case, we've got REASON_SERVERREQUEST
, because the website included content-disposition:attachment. The comment suggests that "Opening attachments in helper apps by default breaks some websites (esp. if the attachment is one part of a multipart document)." I wonder if that's still the case, and I also wonder if we can detect the multipart case to avoid breaking all the other ones.
This code got added in bug 236541, and improving the state of things for content-disp: attachment is bug 453455, so let's dupe this over there...
Description
•