Closed Bug 1332562 Opened 7 years ago Closed 7 years ago

dm file is not shown in Gallery

Categories

(Firefox for Android Graveyard :: Download Manager, defect, P3)

50 Branch
Other
Android
defect

Tracking

(firefox52- verified, firefox-esr52 fixed, firefox53 verified, firefox54 verified)

RESOLVED FIXED
Firefox 54
Tracking Status
firefox52 - verified
firefox-esr52 --- fixed
firefox53 --- verified
firefox54 --- verified

People

(Reporter: lgbrowser5, Assigned: mkaply)

References

Details

Attachments

(2 files)

Attached video record.mp4
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3; CNS_UA; GWX:MANAGED; AD_LOGON=4C47452E4E4554; rv:11.0) like Gecko

Steps to reproduce:

1. Platform Version (M): NOS(7.0)
2. Firefox version (M): Firefox 50.1, Firefox Beta 51.0
3. Reproducible on LG Ref. device (M) : No / G5 device
4. Reproduce rate (M) : 100%
5. Issue Reported (M) : TD
6. Issue Description (Wrong behavior) (M) : dm file is not shown in Gallery or File manager (The file is displayed in Downloads)
7. Expected behavior (M) : The downloaded file should be displayed in Gallery or File manager
8. Steps to reproduce (M) : 
Firefox > wap.lge.com > MC_Multimedia > OMA 1.0 > image > image 01 FL.dm download
9. Screen Capture (M) : Yes
10. MORE INFORMATION (O): dm file is download by Download Manager and the path is InternalStorage/Android/data/org.mozilla.firefox/files/Download
Please check dm download path.

When it fixed, please share Engineering Report or Release info. for patches. 


Actual results:

dm file is not shown in Gallery or File manager (The file is displayed in Downloads)


Expected results:

The downloaded file should be displayed in Gallery or File manager
Summary: dm file is not shown in gallery → dm file is not shown in Gallery
OS: Unspecified → Android
Priority: -- → P3
Hardware: Unspecified → Other
This would be a feature request. Such behavior is not expected unless the image gallery app scans the /sdcard/download/ folder for new files, which would be outside Firefox's control.
Since this issue is related to the downloads side, I'm moving this report to the Download Manager component.
Component: General → Download Manager
When it fixed??
It is not in progress
I hope you can check this issue. 
When it fixed ??
Flags: needinfo?(miket)
Redirect to Mike Kaply.
Flags: needinfo?(miket) → needinfo?(mozilla)
Are your OMA testcases accessible somewhere?
Flags: needinfo?(mozilla)
Does this work on Chrome? The dm file is not necessarily an image (it's just a package file) so I'm unclear why you would expect it to show up in the gallery...
Dear Google
Could you check my inline comment on Comment 1?

- What does DM stand for?
DM is the file extention of the OMA DRM 1.0 Foward-lock(FL)/Combind Delilvery(CD) file.

- What does DD stand for?
DD is the file extention of the OMA Download Descriptor file.

- What is DM content?
DM content is the DRM protected content which is encrypted by OMA DRM FL/CD specification.

1. Open a wap session and connect to the URL <http://www.todoloultimo.net/jprueba_descargas/homePage.do>
 <http://emocion.movistar.es/emocionweb/music.jsp> or <http://wap.movistar.com>
 2. Select 'Mi emocion' > "Mis suscripciones" > "Tarifa plana MP3"
 3. Download a content mp3 or AAC with DRM rights
 4 No way to play downloaded mp3.

Chrome fixed on M57 as below
https://bugs.chromium.org/p/chromium/issues/detail?id=675559
Flags: needinfo?(mozilla)
We do have code to do this. I think it's possible we're missing some OMA mime types. See:

https://dxr.mozilla.org/mozilla-central/source/mobile/android/components/HelperAppDialog.js#12

const OMA_DOWNLOAD_DESCRIPTOR_MIME_TYPE = "application/vnd.oma.dd+xml";
const OMA_DRM_MESSAGE_MIME = "application/vnd.oma.drm.message";
const OMA_DRM_CONTENT_MIME = "application/vnd.oma.drm.content";
const OMA_DRM_RIGHTS_MIME = "application/vnd.oma.drm.rights+wbxml";

We currently forward those mime types to the download manager based on a pref with is set in your distribution - browser.download.forward_oma_android_download_manager.
Flags: needinfo?(mozilla)
If you look at:

https://bugs.chromium.org/p/chromium/issues/detail?id=675559

the chrome bug you referenced, they switched things to have the same behavior as us - downloads passed to the download manager, not downloaded via chrome. They do not specifically send things to the gallery.

It says:

> For OMA DRM downloads, if download descriptor file doesn't exist, Android DownloadManager should be used.
> This CL reverts some of the changes in https://codereview.chromium.org/2341643008 to intercept such downloads.

My understanding is that it is the responsibility of the download manager to make sure that the correct thing is done with the DM files, not the browser.

As a side note, here is an easier test page.

http://116.228.149.59/DRM/qiuyu/drm/htm/Image.htm
OK, so we have some additional detail on this. The issue is the download location. Even though we are using the Android Download manager, the file is being placed in:

/storage/emulated/0/Android/data/org.mozilla.firefox/files/Download/

instead of

/storage/emulated/0/Download

Looking at the code - https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#2074

We're setting the download directory to Environment.DIRECTORY_DOWNLOADS which apparently is incorrect. Environment.DIRECTORY_DOWNLOADS is just "Downloads" so it's not specifying the full path.

Chrome is explicitly setting it to the external downloads directory at the end of the download I think:

                    request.setDestinationInExternalPublicDir(
                            Environment.DIRECTORY_DOWNLOADS, info.getFileName());

https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerService.java?type=cs&q=enqueueDownloadManagerRequest+package:%5Echromium$&l=894

Bringing in sebastian who might know the simplest way to fix this.
Actually, I can just do the same thing Chrome is doing. Testing now.
[Tracking Requested - why for this release]: Very important for partner. I should have a one line low risk by EOD.
> Actually, I can just do the same thing Chrome is doing. Testing now.

We don't have permission to write there, so I'll need to add some permissions code in order to fix.
Use public downloads directory for OMA downloads and ask for permission
Assignee: nobody → mozilla
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #8840482 - Flags: review?(snorp)
Comment on attachment 8840482 [details] [diff] [review]
Use public downloads directory for OMA download

Review of attachment 8840482 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/java/org/mozilla/gecko/BrowserApp.java
@@ +1884,5 @@
>                  final DownloadManager.Request request = new DownloadManager.Request(Uri.parse(uri));
>                  request.setMimeType(mimeType);
>  
>                  try {
> +                    request.setDestinationInExternalPublicDir(Environment.DIRECTORY_DOWNLOADS, filename);

It looks like the indentation is hosed? Or splinter review sucks.
Attachment #8840482 - Flags: review?(snorp) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/564e1f5f214523adc78b1f5ee5a94428c8696343
Bug 1332562 - OMA Downloads should go to the system Download directory. r=snorp
https://hg.mozilla.org/mozilla-central/rev/564e1f5f2145
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 54
Comment on attachment 8840482 [details] [diff] [review]
Use public downloads directory for OMA download

Approval Request Comment
[Feature/Bug causing the regression]: OMA DRM Downloads don't work correctly on partner devices
[User impact if declined]: Partner devices won't do OMA DRM downloads properly
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: Not yet, builds aren't done.
[Needs manual test from QE? If yes, steps to reproduce]: No. 
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: Very low
[Why is the change risky/not risky?]: Change hidden behind a partner pref and very minor change.
[String changes made/needed]: None

I realize this is late in the cycle for this change, but we are working towards finalizing everything for this partner and this is an important bug for them.
Attachment #8840482 - Flags: approval-mozilla-beta?
Attachment #8840482 - Flags: approval-mozilla-aurora?
I'm a bit concerned about the combination of no automated tests, not yet tested in nightly and no manual testing from QE...
I realized I was thinking wrong about manual testing from QE. This can be tested without a distributor build. Test steps are:

go to about:config.
Change the preference browser.download.forward_oma_android_download_manager to true
Go to
http://116.228.149.59/DRM/qiuyu/drm/htm/Image.htm

Attempt a download.
1. Verify that you are asked for permission (agree to the permission)
2. Verify that the file was downloaded into /storage/emulated/0/Download (Might need to use adb shell).

I'll test as soon as a nightly is ready.

As far as automated tests go, I'm honestly not sure how to write them.
Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(brindusa.tot)
Comment on attachment 8840482 [details] [diff] [review]
Use public downloads directory for OMA download

change download directory for OMA download, aurora53+, beta52+
Attachment #8840482 - Flags: approval-mozilla-beta?
Attachment #8840482 - Flags: approval-mozilla-beta+
Attachment #8840482 - Flags: approval-mozilla-aurora?
Attachment #8840482 - Flags: approval-mozilla-aurora+
I will move this to Fennec team, as I am not part of it. Ioana, could you or someone from you team, take a look on this? Thanks!
Flags: needinfo?(brindusa.tot) → needinfo?(ioana.chiorean)
Thanks Brindusa! Sorina will work on it.
Flags: needinfo?(ioana.chiorean) → needinfo?(sorina.florean)
QA Contact: sorina.florean
needs rebase for beta
Flags: needinfo?(mozilla)
:Tomcat,

The attached diff applies to beta. There was a code formatting change that I made with I checked into aurora and ibound.
Flags: needinfo?(mozilla)
Devices:
 - HTC Desire 820 (Android 6.0);
 - Samsung Galaxy Note 4 (Android 5.1.1).

Hello,
 I have verified this issues following the steps provided in Comment 21.

1. There was no prompt asking me for permissions on any of the devices I used for testing.
2. The file was saved in the specified path.
Flags: needinfo?(sorina.florean)
Depends on: 1343213
This issue was verified on 52.0b10 using the STR from Comment 21.

Indeed, the download path is displayed as expected in /storage/emulated/0/Download. 

The matter of download permission is different though.
On Android 5.0.2 (Sony Xperia Z2 tablet) the download permissions are accepted at the install phase so, no notification displayed.

On Android >6 (Samsung Galaxy Note 5 phone) the permissions can be checked/unchecked at will from the app settings menu. So after trying this multiple times a problem with the permission notification was found ( Bug 1343213 )
Verified as fixed on all branches 52.0b10, 53.0a2 (27.02.2017), 54.0a1(27.02.2017) on a Samsung Galaxy Note 5(Android 6.0.1) and on a Sony Xperia Z2 (Android 5.0.2)
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.