Google Play music hijacking MP3 downloads |
||||
Issue descriptionVersion: 54.0.2826.2 OS: Android MMB29K What steps will reproduce the problem? (1) Visit any song page from djpunjab.com, e.g., http://djpunjab.com/single-track/tiger-tittle-track-sippy-gill-mp3-song-280957.html (2) Click on the link to "Download in 128 Kbps" (for example). http://s1281.ve.vc/data/128/38341/280957/Tiger%20-%20Tittle%20Track%20-%20Sippy%20Gill%20(DjPunjab.Com).mp3 What is the expected output? The song will download via the regular Chrome downloads flow. What do you see instead? A popup window shows up with a fuzzy-looking spinner (see first screenshot). The spinner eventually disappears and is replaced by a MP3 playback window. There is no ability to save the MP3 file. Looking at an Android bugreport it looks like Chrome is sending an intent which is being captured by Google Play Music with the package name "com.google.android.music.AudioPreview". Unfortunately, this UI does not provide any means for the user to download the MP3 file -- so it's a broken experience. Note that this does not happen in UC Browser, which lets the user download the file. Also, I see this behavior **after** resetting app preferences in the Android settings menu. This means that I was never given a chance to select this flow as my preferred flow for playing back MP3 files -- Google Play Music seems to be interposing on these requests. From a netlog (also attached) when tapping on this link, it looks like the response is simply Content-Type: audio/mpeg3. t=6182 [st=178] +HTTP_TRANSACTION_SEND_REQUEST [dt=1] t=6182 [st=178] HTTP_TRANSACTION_SEND_REQUEST_HEADERS --> GET /data/128/38341/280957/Tiger%20-%20Tittle%20Track%20-%20Sippy%20Gill%20(DjPunjab.Com).mp3 HTTP/1.1 Host: s1281.ve.vc Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; Nexus 6 Build/MMB29K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2826.2 Mobile Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Referer: http://djpunjab.com/single-track/tiger-tittle-track-sippy-gill-mp3-song-280957.html Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 t=6183 [st=179] -HTTP_TRANSACTION_SEND_REQUEST t=6183 [st=179] +HTTP_TRANSACTION_READ_HEADERS [dt=145] t=6183 [st=179] HTTP_STREAM_PARSER_READ_HEADERS [dt=144] t=6328 [st=324] HTTP_TRANSACTION_READ_RESPONSE_HEADERS --> HTTP/1.1 200 OK Server: nginx/1.8.1 Date: Mon, 15 Aug 2016 19:44:39 GMT Content-Type: audio/mpeg3 Content-Length: 7090969 Last-Modified: Sun, 14 Aug 2016 19:10:05 GMT Connection: keep-alive ETag: "57b0c20d-6c3319" Accept-Ranges: bytes
,
Sep 12 2016
Ping?
,
Sep 13 2016
Min, can you take a look and see if we can figure out why this is happening?
,
Sep 13 2016
Search for "use system download manager" in chrome://flags, that should be set to "DISABLED" to disable System DownloadManager. And once that is set, Chrome will try to download the file instead of doing navigation interception. This flag makes sure all the download goes through chrome network stack. Without it, downloading a file might fail, although external navigation might also fail.
,
Sep 13 2016
Are we expecting end users to know about this flag and use it? the concern here is that anyone trying to use Chrome to download an MP3 file is unable to do so as long as Google Play Music is hijacking the download. This does not seem like the desired behavior.
,
Sep 13 2016
This feature is still not fully rolled out as we are studying its impact, hopefully it is going to be 100% for M54. on M53, this is 10% on stable, 50% on Beta
,
Sep 13 2016
And for M52 users they really want to download a MP3 or a video file, they can always long press the link, and select "download link" from context menu
,
Sep 13 2016
I see, so with the appropriate setting of flags, this should do the right thing? I would claim this is not "WontFix", but rather either "Fixed" or a dupe of another bug in that case.
,
Sep 13 2016
Yes. External navigation has a problem that the external app may not be able to access the target url, due to missing certificate or cookies, etc. So download is a the safer option. However, if download goes through Android DownloadManager, then it could still fail to download the content with the same reasons. As a result, we change the behavior to download only when system DownloadManager is disabled. |
||||
►
Sign in to add a comment |
||||
Comment 1 by dah...@chromium.org
, Aug 15 2016