Make WordPress Core

Opened 6 months ago

Closed 2 months ago

#61809 closed defect (bug) (worksforme)

Firefox Does Not Recognize MIME Types

Reported by: rubickscube's profile rubickscube Owned by:
Milestone: Priority: normal
Severity: normal Version: 6.6
Component: Media Keywords: reporter-feedback close
Focuses: Cc:

Description

With documents hosted in the media library, Firefox does not automatically recognize when a file should be downloaded and when it should be rendered in the browser and defaults to rendering it in the browser, resulting in gibberish when selecting certain files types, such as doc and docx.

The same issue does not exist in chromium-based browsers, which appear to make this distinction automatically. The bug appears to persist across desktop and mobile in the respective browsers.

I've investigated the potential cause and it appears to be that without the MIME Type included in the header, Firefox automatically renders all documents in the browser and fails to determine the appropriate action for different file types. When going directly to the URL of a file in the media library, the MIME Type is absent from the header.

Change History (5)

#1 @dmsnell
6 months ago

When going directly to the URL of a file in the media library

I see two links, one labeled View (like {SITE_URL}/?attachment_id=705) and one labeled Download (like {SITE_URL}/wp-content/uploads/2024/08/20-verbia.docx)

The view link redirects to the full Download link, and they both contain a Content-type header.

HTTP/1.1 200 OK
Host: localhost
Date: Mon, 05 Aug 2024 21:59:47 GMT
Connection: close
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Content-Length: 8255

In Safari and Firefox on macOS both viewed a PDF upload in the browser but downloaded the DOCX. Are you seeing this behavior for all files, or is there a specific file you are having trouble with?

Do you have any extensions installed in Firefox that would attempt to load support for rendering the DOCX type? For example, I think Microsoft Office has a browser plugin for doing just this.

#2 @desrosj
6 months ago

  • Keywords reporter-feedback added

#3 @adamsilverstein
6 months ago

@rubickscube note that if you are requesting the document(s) directly from your web serving (by loading its full URL), the web server delivers the file and headers. WordPress is not involved in serving the file in this case, and its up to the web server to set the correct content-type header. If this is the case and the docx type is missing, you can add it in .htaccess with AddType

#4 @hellofromTonya
4 months ago

  • Keywords close added

Hello @rubickscube,

Welcome to WordPress Core's Trac.

I'm doing triage today. I'm finding how this issue was introduced in the 6.6 cycle. Thus, removing Version.

Have you had a chance to follow-up with the hints and questions previously shared / asked? Will much appreciate if you can comment with your findings.

Marking this ticket as close candidate, as it does not appear actionable and is in need of reporter-feedback. Let's give the reporter a couple more weeks to respond before closing.

#5 @karmatosed
2 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Thank you for the triage @hellofromTonya and also for the report @rubickscube. As there hasn't been any updates to this and the close recommendation was added with a suggestion to leave for a few weeks, I am going to now go through and follow through with that. This doesn't mean it can't be reopen once that requested extra information is provided and it becomes actionable.

Again, thank you everyone. For now, using status of works for me as this isn't replicating for others.

Note: See TracTickets for help on using tickets.