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

Issue 852629 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Prefetched page shared through Inbox app can not be opened in Chrome

Project Member Reported by dim...@chromium.org, Jun 14 2018

Issue description

Android: 8.1.0
Chrome: Canary 69.0.3456.0 (or Dev 69.0.3452.0, same behavior)
Google Inbox App: 1.72.196205970

1. In Chrome, go to Downloads->Popular pages from Chrome->open any prefetched article. Should open in CCT (if not, set a flag that opens offline pages in CCT, I didn't verify without it)
2. Click 3-dots, Share -> Share to yourself using Inbox app.
3. In Inbox app, open newly arrived email, click on attached mhtml page.
4. In "Open With", select Intent Analyser - verify that mime type is "multipart/related"
5. In "Open With", select Chrome Canary or Dev - it will download the file instead of opening it, and ADM will record it as application/octet mime type.

 

Comment 1 by dim...@chromium.org, Jun 14 2018

Additional info: if I open the same email in desktop web-based Inbox, and downloaded mhtml file, subsequent opening of it in desktop Chrome works just fine.
This seems to happen from inbox, but not from GMail.  Although the mime type is reported as multipart/related, the content URI has a tag at the end which might be overriding the mime type to application/octet-stream :

content://com.google.android.apps.docs.fetcher.FileProvider/eULmT5aRl7e-V6D0-KHMf7Vo8alWKbYImEC6_0cpKa0%3D?_display_name=315a58b1-4521-44c1-9d94-e4b88bc05376.mhtml&mime_type=application%2Foctet-stream&_size=1538911

This also happens on Android N and Android P, it is not Oreo specific like the  ADM bug was.  It appears to be a bug in Inbox.  Let's contact the Inbox team to see if they can fix it on their side.
One potential fix we discussed was to have Chrome use the mime type from the intent instead of the mime type from the URI.
Project Member

Comment 5 by bugdroid1@chromium.org, Jun 19 2018

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

commit 4287efebc986570c4e18e1dc3ecf9f6a73d99e0c
Author: Pete Williamson <petewil@chromium.org>
Date: Tue Jun 19 18:47:10 2018

Override Content URI mime type whenever we have a mime type used by MHTML.

For some apps (Inbox), we discovered the mime type in content uri and
contentProvider.getType() doesn't match the mime type in the intent.
To prevent that from making chrome think the file is really a download,
we now set headers whenever we see a mime type in the intent that
is used by MHTML.

Bug:  852629 
Change-Id: I874e2c976a9817d3a35b8587044f7589c2d498e8
Reviewed-on: https://chromium-review.googlesource.com/1103592
Reviewed-by: Jian Li <jianli@chromium.org>
Reviewed-by: David Trainor <dtrainor@chromium.org>
Commit-Queue: Peter Williamson <petewil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568541}
[modify] https://crrev.com/4287efebc986570c4e18e1dc3ecf9f6a73d99e0c/chrome/android/java/src/org/chromium/chrome/browser/IntentHandler.java
[modify] https://crrev.com/4287efebc986570c4e18e1dc3ecf9f6a73d99e0c/chrome/android/javatests/src/org/chromium/chrome/browser/IntentHandlerTest.java

Status: Fixed (was: Assigned)

Sign in to add a comment