Closed Bug 1725190 Opened 3 years ago Closed 2 years ago

Incorrect file extension when downloading CR3 files

Categories

(Core :: Audio/Video, defect, P2)

Firefox 91
defect

Tracking

()

VERIFIED FIXED
97 Branch
Tracking Status
firefox97 --- verified

People

(Reporter: qyvkcvqjcktvupqzpj, Assigned: jbauman)

References

(Blocks 1 open bug)

Details

Attachments

(6 files)

Attached image Steps to reproduce

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:

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

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.

Component: Untriaged → File Handling

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?

Flags: needinfo?(jbauman)

Sorry, they contain ftypcrx, "normal" MP4s contain ftypmp42. I think we should just return false for "crx" in MatchesMP4.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: mimesniff

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.

Flags: needinfo?(jbauman) → needinfo?(jolin)
Component: File Handling → Audio/Video
Product: Firefox → Core

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

Flags: needinfo?(jolin)

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 :-)

I'll take a look at trying this change, probably sometime next week

Assignee: nobody → jbauman
Severity: -- → S3
Priority: -- → P2

This has gotten delayed by some work that needs to happen before the 93 release, but it hasn't been forgotten

Attachment #9243968 - Flags: data-review?(chutten)

Fix clang-tidy lints

Depends on D127291

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+

Attachment #9243968 - Flags: data-review?(chutten) → data-review+
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

Adding "leave-open" flag while we evaluate the telemetry to see whether we can change the default behavior

Keywords: leave-open

Looking at the data for beta 95 ftyp_iso is at 64.31%.

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.

The next commit (described in comment 19) should close out this issue

Keywords: leave-open
Pushed by jbauman@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6dddcf3ed69f
Incorrect file extension when downloading CR3 files. r=jolin
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
Flags: qe-verify+

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

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

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: