probably related to https://bugs.chromium.org/p/chromium/issues/detail?id=585422

Confirmed.

This isn't actually the same as  Issue 585422  (I tried my fix, and it did nothing).

Some more details. The HTTP request to download this file from Google Drive is responding with this Response Header:

Content-Disposition: attachment;filename="_______________R.pdf";filename*=UTF-8''%E5%B2%A1%E5%B1%B1%E3%80%80%E5%B2%A1%E5%B1%B1%E3%80%80%E6%A7%98%E9%82%B8%E3%80%80%E5%9B%B3%E9%9D%A2%E3%80%80%E6%96%B0%E5%89%B5%E8%93%84R.pdf

Breaking this down, this says:

- Please download this file (don't show it to the user).
- If you only support ASCII, the filename is "_______________R.pdf".
- If you support UTF-8, the filename is "%E5%B2%A1%E5%B1%B1%E3%80%80%E5%B2%A1%E5%B1%B1%E3%80%80%E6%A7%98%E9%82%B8%E3%80%80%E5%9B%B3%E9%9D%A2%E3%80%80%E6%96%B0%E5%89%B5%E8%93%84R.pdf", decoding those percent-encoded sequences.
  - That decodes as "岡山　岡山　様邸　図面　新創蓄R.pdf".

So Google Drive is responding correctly. Chrome is erroneously not decoding "%E3%80%80" sequences, because they are blacklisted for visual spoofing reasons.

I'm starting to realise this is a widespread issue in many parts of the code base. It's the same root cause as  Issue 585422  but likely in a different part of the code base. I've just filed Issue 849998 to track these issues generally.

As part of this fix, we should address the following special case: a file with '/' in it (or '\' on Windows) is legal in Google Drive. Chrome currently saves '/' as "%2F" (not because anyone specifically designed it this way, but because Chrome doesn't unescape heaps of characters like this). After this fix, we should decode it as '_', which is consistent with how we decode all other illegal characters (like '?') on Windows, and also how Firefox decodes '/'.

I tested a quick fix by making UnescapeRule::URL_SPECIAL_CHARS_EXCEPT_PATH_SEPARATORS unescape *all* characters except slashes. The above was fixed.

I'm still tossing up whether to try and commit this, or do a more targeted ("proper") fix as discussed in Issue 849998.

Other JP enterprise customer has reported the same issue.
Chrome version: 67.0.3396.87 
OS version:Mac 10.11 
Case#:16120161
Drive link to screenshot: 
https://drive.google.com/open?id=19okG3PYb-OgN3NAHVy2PEHMhQHL2L46k
Able to reproduce at locally? : Yes

Any updates for customer please?

Hi,

I was going to get to it this week, but was unable due to some other things that came up. This is on my priority for next week.

Any new information regarding this bug?  Looking for updates to inform the customer as they are inquiring.  Also looking to find out what Chrome release this will be targeting as this is still labeled for M-67.

This will be fixed as part of a big refactor I'm doing: https://chromium-review.googlesource.com/c/chromium/src/+/1152629

I'll try to have it landed for M70.

If necessary, I could just fix downloads as a special case, but we may as well fix everything (since the same bug is seen throughout Chrome; Issue 849998).

I've put up a CL https://crrev.com/c/1209003 to just address this specific issue. It's much simpler and should be mergeable.

Thanks, please do merge to 69. Requesting.

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is regressed in M67 and M69 is already in stable. Pls target fix for M70 and request a merge.

Also cl listed at #12 is not yet landed in trunk, so it is too late to consider this merge for M69.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/25c6a34f13cf711fcd23e8f6d87b00c701fe7340

commit 25c6a34f13cf711fcd23e8f6d87b00c701fe7340
Author: Matt Giuca <mgiuca@chromium.org>
Date: Fri Sep 07 00:48:17 2018

Fixed downloaded filenames containing percent-encoded characters.

Servers set the download filename in a URL syntax (either through the
Content-Disposition header, or in the filename of the requested URL
itself). Previously, characters would remain percent-encoded when saved
to disk, if they are deemed unsuitable for display. This criteria makes
no sense for setting a filename.

Cases included:
- Control characters.
- Path separators.
- Special URL characters such as '%', '+', '&' and '#'.
- Spoofing characters, such as invisible characters.

Now, all characters are unescaped. Characters that are illegal in
filenames (such as control characters, path separators, colons, etc) are
converted into underscores. Other characters are left bare.

Fixed and added tests.

Bug:  849794 
Change-Id: I797ee3d6aa8b803d9a7227e821fd8b4d55d0c58d
Reviewed-on: https://chromium-review.googlesource.com/1209003
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Matt Giuca <mgiuca@chromium.org>
Cr-Commit-Position: refs/heads/master@{#589386}
[modify] https://crrev.com/25c6a34f13cf711fcd23e8f6d87b00c701fe7340/net/base/filename_util_internal.cc
[modify] https://crrev.com/25c6a34f13cf711fcd23e8f6d87b00c701fe7340/net/base/filename_util_unittest.cc
[modify] https://crrev.com/25c6a34f13cf711fcd23e8f6d87b00c701fe7340/net/http/http_content_disposition.cc

Fix just landed.

Please don't merge-request things that haven't landed yet (or, generally, other people's fixes). I'm working on this.

Removing merge request. Standard procedure is to wait for the change to land in Canary and manually test it. Then I'll request a merge (to 70, not 69).

I'm trying this on Canary 71.0.3549.0 (Windows) and unexpectedly still seeing the broken behaviour. I'm not sure why. I will keep investigating.

#20 Sorry, it's actually 71.0.3549.1 (not that that should make a difference).

Well, this is embarrassing. It turns out I fixed this for URL-path filenames and "C-D: filename=", but not "C-D: filename*=", which is what Google Drive uses, and has a different code path.

I built my own test app which used "filename=" and I must've forgotten to test the original fix with Google Drive.

https://crrev.com/c/1221006 is a new CL that patches "filename*=" and adds new tests.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ee4ef82bf9b1b569285b0a046217aeda8a684691

commit ee4ef82bf9b1b569285b0a046217aeda8a684691
Author: Matt Giuca <mgiuca@chromium.org>
Date: Thu Sep 13 02:26:36 2018

Fixed downloaded filenames containing percent-encoded characters [Part 2].

Correctly decodes percent-encoded characters in the "filename*" field
of a Content-Disposition response header.

Follow-up to r589386, which unintentionally left off a crucial change.
In the original CL, download filenames were properly percent-decoded
when they came from the URL path, or the "filename" field of a
Content-Disposition header. This CL applies the same logic when
filenames come from the "filename*" field (which is the same as
"filename" but also includes the charset, and is processed on a
different code path).

Bug:  849794 
Change-Id: I4e3586a070deabd4df9785c9c62568fe1fe147f5
Reviewed-on: https://chromium-review.googlesource.com/1221006
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Matt Giuca <mgiuca@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590899}
[modify] https://crrev.com/ee4ef82bf9b1b569285b0a046217aeda8a684691/net/http/http_content_disposition.cc
[modify] https://crrev.com/ee4ef82bf9b1b569285b0a046217aeda8a684691/net/http/http_content_disposition_unittest.cc

Should now be fully fixed. Will wait for next Canary to test and merge-request (unfortunately will have to merge both CLs).

Missed today's Canary (71.0.3551.0). Will check again on Monday.

Tested on Canary 71.0.3553.2. Verified fix.

Requesting a merge of the above two CLs to M70:
- r589386
- r590899

Rationale: This regressed some time ago (M67 I believe), but enterprise customers have been requesting a fix for some time. However, there is no security or M70-regression case for this merge, so it's at the discretion of release manager.

Likelihood of breakage: Low. This does not change any code outside of the part that determines how to name downloaded files.

This bug requires manual review: M70 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thank you for more feedback. Let's target the fix for M71, if this has been broken for over 3 releases now.