Closed Bug 671172 Opened 13 years ago Closed 13 years ago

Can not select pdf files in File Upload dialog

Categories

(Core :: Widget: Cocoa, defect)

5 Branch
All
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 646854

People

(Reporter: Lewis, Unassigned)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Build ID: 20110318052756

Steps to reproduce:

After upgrading to 5 (this worked in 4) I can not select a PDF file in the File Upload dialog that appears when I click the Browse button next to an HTML file type input element. The specific HTML element source code has the attribute: ACCEPT="image/*". I can select image files such as jpg, png, tiff, etc. But not PDF. This worked great in Furefox 4 and works in the latest version of Safari.

The HTML code for the form element is:

INPUT TYPE="file" NAME="file_1" ACCEPT="image/*" SIZE=35


Actual results:

The File Upload dialog lists all files with PDF extension as dimmed and not selectable in Firefox 5.


Expected results:

Should have been able to select  pdf file in the dialog.
OS: Other → Mac OS X
Hardware: All → x86
Can you provide a link with the issue?
Component: File Handling → General
QA Contact: file.handling → general
I can not send a link to the problem. It occurred on a page of a federal court website that I logged on to using a secure log in which I can not share.

I did copy the HTML code for the file input element on that page where the problem arose.

I do not have this problem where the input element attribute 'ACCEPT' is not set to define allowable file types. However the 'ACCEPT="image/*"' attribute I supplied does work properly as set in Firefox 4 and Safari.
If this worked in FF4, this sounds like we should figure out when this behaviour changed.
The only help I can provide in that regard is to say the problem began when I upgraded from 4 to 5. I can not help track minor beta changes as I am not involved in development at that level.

I assume I have been upgraded, by Firefox's Software Updater, to the most current version of 4 before it upgraded me to 5.
Mounir, the accept handling code that I'm looking at in nsHTMLInputElement.cpp was last changed by you, but that looks like it happened before FF4 was released. Any ideas here? Is this actually a bug, since the input says it accepts image/* and I presume that PDFs are some other type?
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
PDFs are application/pdf.  And the HTML5 spec says at http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#attr-input-accept

  User agents should prevent the user from selecting files that are not accepted
  by one (or more) of these tokens.

That said, at least over here I can select the "All Files" filter in the filepicker instead of the default-selected "Image Files" one, and pick whatever I want.

Safari simply seems to have no support for @accept on <input type="file">.  Chrome behaves as we do, but without the "All Files" out.

Lewis, if this site really expects people to upload PDFs, then it's using the wrong value for the "accept" attribute....  Can you possibly report this problem to the site's maintainer?
I will notify them that FF5 strictly adheres to HTML5 specifications and they should change the file input element "ACCEPT" attribute value to "image/*, application/pdf".

Would that be a correct way to phrase it?
That seems reasonable, but Mounir should confirm...
(In reply to comment #7)
> I will notify them that FF5 strictly adheres to HTML5 specifications and
> they should change the file input element "ACCEPT" attribute value to
> "image/*, application/pdf".
> 
> Would that be a correct way to phrase it?

That would be correct per HTML5 specifications. Though, we (as in Firefox) do not support MIME types for the moment. If you include a MIME type in addition of "image/*" we will allow the user to select anything (to degrade gracefully). If the website actually wants you to upload an image OR a pdf, they should probably do that.

However, about the Firefox implementation, we've never wanted to force the user to only select valid files (wrt to the accept attribute) because websites might be wrong and the list of extensions we are using for images, videos and audio might be wrong too. In addition, this filtering is only here to help the user not to annoy him/her; it should not replace server side checks.
I see you are using MacOS X and because of a bug in our MacOS X code, the accept attribute was ignored with this platform in Firefox 4 [1]. I did fix that for Firefox 5 but MacOS X doesn't allow you to change a filter natively so I had to add a dropdown list of filters in the MacOS X file picker to allow it [2] but the fix will only be available with the next version of Firefox (the update should happen early August). Unfortunately, I though websites using the accept attribute were not very common (and those using it wrongly even less) so I though having the fix in the next version wouldn't hurt anyone. Sorry about that.

A very simple solution for you would be to use Firefox Beta [3] when you want go to this website. With Firefox Beta, you should be able to change the filter to "All files" and upload your PDF as described by Boris in comment 6.

I'm marking this bug RESOLVED but feel free to add a comment if you have any question.

[1] bug 643576
[2] bug 646854
[3] https://www.mozilla.com/firefox/channel/
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Component: DOM → Widget: Cocoa
QA Contact: general → cocoa
Hardware: x86 → All
Thank you for the information. I have passed this on to the site developer. Not sure how to get the beta, but I will continue to use FF4 until the August release.
You can get the beta at http://www.mozilla.com/en-US/firefox/channel/

I strongly recommend using the 6 beta instead of Firefox 4, since Firefox 4 has known security holes that are patched in 5 and beta...
Done. I am now on the beta release channel.
You need to log in before you can comment on or make changes to this bug.