UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce the problem:
1. create an extension with the following background page
code and the 'download' permission:

chrome.downloads.onDeterminingFilename.addListener(function(download, suggest) {
    console.log('ondeterminingfilename download:', download);
});

alternatively install the attached extension.

2. open the background page developer tools and put a break point inside the onDeterminingFilename callback.

3. go to http://www.aoml.noaa.gov/ocd/necop/pkunzip/manual.doc

4. examine the download http response mime type, and compare it to download.mime

What is the expected behavior?
When the debugger reached a break point inside onDeterminingFilename callback, the value of download.mime should be identical to that of the response: application/msword

What went wrong?
When the debugger reached a break point inside onDeterminingFilename callback, the value of download.mime is "application/octet-stream", while the mime type of the response is "application/msword". they should be the same.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 67.0.3396.99  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

The wrong behavior does not reproduce for all download links
 

Deleted: test_extension.zip 1.9 KB

test_extension.zip 1.9 KB Download