Closed Bug 1589121 Opened 5 years ago Closed 5 years ago

Cannot open text files in external application

Categories

(Firefox :: File Handling, defect)

69 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 453455

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.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → File Handling

This looks related:

https://searchfox.org/mozilla-central/rev/97976753a21c1731e18177de9e5ce78ea3b3da2d/uriloader/exthandler/nsExternalHelperAppService.cpp#1650

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(gijskruitbosch+bugs)

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...

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(gijskruitbosch+bugs)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.