Incorrect file extension when downloading CR3 files
Categories
(Core :: Audio/Video, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox97 | --- | verified |
People
(Reporter: qyvkcvqjcktvupqzpj, Assigned: jbauman)
References
(Blocks 1 open bug)
Details
Attachments
(6 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
There is a bug with downloading Canon’s CR3 files (RAW image format).
If you download a CR3 file, Firefox automatically change the file extension to .mp4 – instead of CR3.
You can reproduce it like this:
-
Download a CR3 file (for example here below: https://www.dkamera.de/testbericht/canon-eos-m6-mark-ii/beispielaufnahmen.html or here: https://www.dpreview.com/sample-galleries/3577431182/canon-rf-28-70mm-f2-l-sample-gallery-dpreview-tv/9300505795 – it is important, that you download the RAW photo)
-
Save it
-
You will find the file in your location with .mp4 instead of CR3
Please also see the attached screenshot.
With Canon's old file format .CR2, Firefox does not have problems (you can test it here: https://www.dkamera.de/testbericht/canon-eos-70d/beispielaufnahmen.html or here: https://www.dpreview.com/sample-galleries/9485291827/canon-eos-5d-mark-iv-sample-gallery/7296166408 )
Actual results:
Firefox automatically changed the file extension to .mp4
Expected results:
The downloaded file should have .CR3
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•3 years ago
•
|
||
This is a very interesting failure, thanks! These files are served with Content-Type: application/octet-stream
. I think we might sniffing these files as MP4 in MatchesMP4
, because they also contain ftypmp42
?
Comment 3•3 years ago
|
||
Sorry, they contain ftypcrx
, "normal" MP4s contain ftypmp42
. I think we should just return false for "crx" in MatchesMP4
.
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 5•3 years ago
|
||
It looks like we're interpreting these as MP4 due to the minor brand isom
. That was added back in 2016 as part of bug 1269260. Since it's not part of the behavior dictated by the mimesniff spec for MP4, I'm not sure what we should be doing here. John, since you were involved with that change, maybe you have a better idea.
Updated•3 years ago
|
Comment 6•3 years ago
|
||
(In reply to Jon Bauman [:jbauman:] from comment #5)
It looks like we're interpreting these as MP4 due to the minor brand
isom
. That was added back in 2016 as part of bug 1269260. Since it's not part of the behavior dictated by the mimesniff spec for MP4, I'm not sure what we should be doing here. John, since you were involved with that change, maybe you have a better idea.
It is possible that treating 'isom' files as mp4 video is no longer needed, but I don't think that we know how many sites still serve those files. I guess we could add a pref for users to alter the behavior, and at the same time start collecting data to see if this workaround still matters.
Thank you for looking on this.
I just want to inform you, that the same issue is also in Firefox for Android (91.3.0) - you will get an error message: "No video with supported format and MIME type found”.
The workaround sounds nice, looking forward to test it :-)
Assignee | ||
Comment 8•3 years ago
|
||
I'll take a look at trying this change, probably sometime next week
Assignee | ||
Comment 9•3 years ago
|
||
This has gotten delayed by some work that needs to happen before the 93 release, but it hasn't been forgotten
Assignee | ||
Comment 10•3 years ago
|
||
Assignee | ||
Comment 11•3 years ago
|
||
Add failing test
Assignee | ||
Comment 12•3 years ago
|
||
Depends on D127290
Assignee | ||
Comment 13•3 years ago
|
||
Fix clang-tidy lints
Depends on D127291
Comment 14•3 years ago
|
||
Comment on attachment 9243968 [details]
bug-1725190-data_review.md
DATA COLLECTION REVIEW RESPONSE:
Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?
Yes.
Is there a control mechanism that allows the user to turn the data collection on and off?
Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.
If the request is for permanent data collection, is there someone who will monitor the data over time?
Yes, John Lin (jolin@mozilla.com) and Jon Bauman (jbauman@mozilla.com) are responsible.
Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 1, Technical.
Is the data collection request for default-on or default-off?
Default on for pre-release channels only.
Does the instrumentation include the addition of any new identifiers?
No.
Is the data collection covered by the existing Firefox privacy notice?
Yes.
Does the data collection use a third-party collection tool?
No.
Result: datareview+
Comment 15•3 years ago
|
||
Pushed by jbauman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1dabc86bebed Incorrect file extension when downloading CR3 files. r=jolin https://hg.mozilla.org/integration/autoland/rev/c529cef5bc53 Incorrect file extension when downloading CR3 files. r=jolin https://hg.mozilla.org/integration/autoland/rev/42baadc27ce5 Incorrect file extension when downloading CR3 files. r=jolin
Assignee | ||
Comment 16•3 years ago
|
||
Adding "leave-open" flag while we evaluate the telemetry to see whether we can change the default behavior
Comment 17•3 years ago
|
||
bugherder |
Comment 18•2 years ago
|
||
Looking at the data for beta 95 ftyp_iso is at 64.31%.
Assignee | ||
Comment 19•2 years ago
|
||
Yeah, it's not going to be feasible to remove the iso?
-> video/mp4 sniffing, but I plan on adding code to handle the crx
brand and sniff it as application/octet-stream
since it's used for both still images and video. That should resolve the issue of changing the extension to .mp4
at least.
Assignee | ||
Comment 20•2 years ago
|
||
The next commit (described in comment 19) should close out this issue
Assignee | ||
Comment 21•2 years ago
|
||
Comment 22•2 years ago
|
||
Pushed by jbauman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6dddcf3ed69f Incorrect file extension when downloading CR3 files. r=jolin
Comment 23•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Updated•2 years ago
|
Comment 24•2 years ago
|
||
Reproducible on Nightly 93.01a, Firefox 78.0 with the STR provided.
Issue was fixed on latest Firefox 97.0b8 and Nightly 98.0a1 across platforms (Windows 10, macOS 11.6, Ubuntu 18.04).
Comment 25•2 years ago
|
||
(In reply to Ardelean Oana from comment #24)
Reproducible on Nightly 93.01a, Firefox 78.0 with the STR provided.
Issue was fixed on latest Firefox 97.0b8 and Nightly 98.0a1 across platforms (Windows 10, macOS 11.6, Ubuntu 18.04).
Thanks for verifying this issue.
Description
•