<input accept=...> is wrong implemented

RESOLVED DUPLICATE of bug 565274

Status

()

Core
DOM: Core & HTML
RESOLVED DUPLICATE of bug 565274
6 years ago
5 years ago

People

(Reporter: JM Lago, Unassigned)

Tracking

({html5})

16 Branch
x86_64
All
html5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120614114901

Steps to reproduce:

According to W3C (http://www.w3.org/TR/html-markup/input.file.html) the file input type should be accepts the mime type format "[type]/[file_extension]"


Actual results:

However Firefox only accepts filters with a partial mime types without a defined file extension like "image/*" or "text/*". Some web browsers like Chrome allows can use a defined file extensions into the mime type like "image/jpg".

See the example in: http://jsfiddle.net/CCbz7/


Expected results:

Firefox should be accepts also mime types with a defined file extension like "image/jpg" or "text/html".
(Reporter)

Updated

6 years ago
Component: Untriaged → HTML: Form Submission
Product: Firefox → Core

Comment 1

6 years ago
Created attachment 642264 [details]
testcase

Comment 2

6 years ago
FYI
http://jsfiddle.net/CCbz7/ in comment #0 is wrong.
The accept attribute should be "accept", not "accepts"

Comment 3

6 years ago
Created attachment 642267 [details]
Screenshot (in case of accept="image/gif")

Step To Reproduce:
1. Open testcase.
2. Click first input box.
3. Observe filter of the file picker.

Actual result:
  Filter of the file picker selected */* first, and image/gif secondly
  See screenshot

Expected result:
  Filter of the file picker should select image/gif first, not */*

Updated

6 years ago
Blocks: 565274
Component: HTML: Form Submission → DOM: Core & HTML
Version: 13 Branch → 16 Branch

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

6 years ago
OS: Windows 7 → All

Updated

6 years ago
Keywords: html5
Summary: "Accepts" W3C specification is wrong implemented in Firefox for the file input type → <input accept=...> is wrong implemented

Comment 4

6 years ago
Test case works fine with the current nightly (since 565274 has been implemented).
Indeed, it wasn't working with Firefox 13.
So, relying on the first comment, this bug should be marked as duplicated of bug 565274 IMO.

About comment 3, indeed, it's not selected by default, but that's the expected behavior we discussed on bug 565274 (the idea started on comment 14, and is discussed again in next comments).
The main idea is to select a filter by default only if it comes from Mozilla's hard-coded set of values (something we can handle).
Currently, as the mime service resolver also uses OS information, this might result in different mime-types<->file extensions mapping across OSs so it was decided it's more desirable to not select this filter as default, as we can't "trust" it.
Moreover, from what I see in the W3C link you provided, this is compliant with the specification, as the spec only specifies that input should support mime-types in accept attribute when type="file", which is what we do currently.

But maybe we can discuss the current behavior if you think something can be improved.

Updated

6 years ago
No longer blocks: 565274
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 565274

Comment 6

5 years ago
I am really new to bugzilla. I hope I am writing this comment for the right people.

I expect the same result as comment 3. So there are 3 ways for me to follow:

1. Try to convince you that this default behaviour which lists all files is "not so useful"
2. Request from Mozilla to add more "hard-coded set of values".
3. Request for implementation of "file extension filter" mentioned in http://www.w3.org/html/wg/drafts/html/master/forms.html#attr-input-accept

Is it possible to discuss these 3 alternatives here or am I suppose to report three separate bugs?

Comment 7

5 years ago
This bug is closed as duplicate of bug 565274, which is fixed in Gecko/Firefox 16. You may have a look into that bug.
I'v no technical insight here, but usually we have one bug per issue.

> Is it possible to discuss these 3 alternatives here or am I suppose 
> to report three separate bugs?

A closed, duplicated bug is usually not the place for discussions

Comment 8

5 years ago
> usually we have one bug per issue
... one issue per bug I should say
You need to log in before you can comment on or make changes to this bug.