New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 683084 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

[Downloads Home] Unable to open downloaded file ,instead "Cannot display PDF..." toast message is seen

Reported by ppa...@etouch.net, Jan 20 2017

Issue description

Application Version: Chrome 57.0.2987.0
Android Build Number: 6.0.1/MMB29K
Device: Samsung Galaxy J7(SM-J700F)

Steps to reproduce: 
1.Launch Chrome
2.Google search anything ex. google > Turn off internet 
3.Long tap on any link & select 'Download link' from context menu 
4.Go to Downloads from Chrome menu (Observed download paused progress)
5.Turn on internet (wait for a while) > Tap on resume button (observed file is downloaded)
6.Tap on downloaded file > Observe 


Observed behavior: 
Unable to open downloaded file ,instead "Cannot display PDF..." toast message is seen 

Expected behavior: 
User should able to open the downloaded file

Frequency: 
<5/5> 

Additional comments: 
1.This issue is present from 57.0.2957.0 build of M57
2.This issue is reproducible on Samsung Galaxy S4(GTI9500)(5.0.1/LRX22C),Google Pixel (7.1/NDE63V),Spice Mi-498(6.0.1/MOB30W),Karbonn Sparkle V(5.1.1/LMY47V), Samsung Galaxy S3(GTI9300)(4.3/JSS15J), Nexus 7 (6.0.1/MOB30J),Nexus 9(7.1.1/N4F26M),Samsung Galaxy J7(SM-J700F)(6.0.1/MMB29K),Samsung Galaxy J2(SM-J200G)(5.1.1/LMY47X)


 

Comment 1 by ppa...@etouch.net, Jan 20 2017

Please find the log & video @ http://go/chrome-androidlogs1/6/683084
Components: UI>Browser>Downloads
Labels: -Pri-3 M-57 Pri-2 Type-Bug
Owner: dfalcant...@chromium.org
Status: Assigned (was: Unconfirmed)
Cc: dim...@chromium.org dfalcant...@chromium.org
Labels: -Restrict-View-Google
Owner: qin...@chromium.org
Not sure what file you're getting because there's no extension, but the PDF viewer claims to be able to open it and then suddenly decides it can't when we send the file over.  Min/Dmitry: do you know what kind of file is supposed to saved here?  Maybe the MIME type is set incorrectly?  Don't remember if offline pages was supposed to be taking this type of download over.

Comment 4 by qin...@chromium.org, Jan 20 2017

It looks to me that the "download link" actually goes through 2 different code path when the click was registered with network on/off.

If the network in available, the download goes through offline page code path.
Otherwise, I will see the duplicate infobar, and seems it is going through chrome's regular download path.

Comment 5 by qin...@chromium.org, Jan 21 2017

ok, i found why this situation is handled differently.
in case network fails, offline page's ResourceThrottle::WillProcessResponse() will not get called. That's causing Chrome treating it as a regular download.

Comment 6 by qin...@chromium.org, Jan 23 2017

When resuming a interrupted download, it is possible that the download has no prior MIME info due to network error. And UrlDownloader may be used for the resumption, and the new MIME type is not passed back to the download item.
Project Member

Comment 7 by bugdroid1@chromium.org, Jan 27 2017

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

commit 521884b60a3ecb3b6ca5081b1e36244c2877e279
Author: qinmin <qinmin@chromium.org>
Date: Fri Jan 27 20:40:59 2017

Fix an issue that download may missing MIME type if it failed ealier

If a download fails before response is started, it will not have MIME type set.
Later when resuming the download, Chrome should reset the MIME type when it becomes available.

BUG=683084

Review-Url: https://codereview.chromium.org/2653833002
Cr-Commit-Position: refs/heads/master@{#446756}

[modify] https://crrev.com/521884b60a3ecb3b6ca5081b1e36244c2877e279/content/browser/download/download_item_impl.cc
[modify] https://crrev.com/521884b60a3ecb3b6ca5081b1e36244c2877e279/content/browser/download/download_item_impl_unittest.cc

This issue is fixed on latest 58.0.3012.0 ,but still reproducible on latest 57.0.2987.52
Requesting for merge to M57.

Sign in to add a comment