1201512 - Downloaded files not appearing in about:downloads until browser restart

Status: RESOLVED DUPLICATE of bug 1211255

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

Description

[Flaviu Cos]

Environment: 
Device: Asus Transformer Pad (Android 4.2.1);
Build: Nightly 43.0a1 (2015-09-03);

Steps to reproduce:
1. Launch fennec;
2. Download a file (e.g.: http://1.usa.gov/deeXKM);
3. Go to about:downloads.

Expected result:
The downloaded file is present in about:downloads.

Actual result:
The downloaded file is not present in about:downloads.

Comment 1

[Flaviu Cos]

The downloaded file appears in about:downloads only after browser restart.

Comment 2

[:Margaret Leibovic]

droeh, could this be related to the work for bug 1163937?

Comment 3

[Dylan Roeh (:droeh) (he/him)]

The fix for bug 1163937 only adds a call to the downloadFiles sanitizer to ensure the DownloadStore is written to disk after sanitizing; nothing outside of the sanitizer should be affected. Also the fix for bug 1163937 was uplifted to 41, and it looks like 41 is unaffected here. I'll take a closer look tomorrow morning just to be sure, but I don't think this is related at first glance.

Comment 4

[Kevin Brosnan [Ex-Mozilla]]

Flaviu would you use mozregression to get regression range?

Comment 5

[Flaviu Cos]

Regression window:
Last good build: 2015-08-27;
First bad build: 2015-08-28;

Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f8086bd3c84fc1a42c3625cf3cc2253f0a5e8cfd&tochange=87e23922be375985d0b1906ed5ba5f095f323a38

Comment 6

[Kevin Brosnan [Ex-Mozilla]]

bug 1009795? Though a one day range is rather big, we should have inbound builds still.

Comment 7

[Flaviu Cos]

Mozregression tool could not find any builds for inbound.
I searched manually and find out that there are no inbound builds between August 27th and August 30th.

But I managed to find a regression range in fx-team:
Last good revision: a812ab9b77bb23fec84afbb303d927100cf7a448
First bad revision: 8b78514a72da184b5e481f7dfa5cf0fe9378b0a3

Pushlog:
http://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=a812ab9b77bb23fec84afbb303d927100cf7a448&tochange=8b78514a72da184b5e481f7dfa5cf0fe9378b0a3

Comment 8

[Sebastian Kaspari (:sebastian; :pocmo)]

This is about to slip into the 42.0 release!

I tried to bisect using the regression range but this is painful with the latest build changes on our side and google moving to SDK23 on their side. I downgraded my support library and used an old-style mozconfig but then it seems like my local google play services version is too advanced (back then we didn't use AARs). Unfortunately I can't downgrade it because I can't guess the download URL like I did with the 22 support library (The current URL is https://dl.google.com/android/repository/google_play_services_8115000_r27.zip but what's the URL for 7.8?)

Anyways, looking at the regression range (2015-08-27 - 2015-08-28) and 42.0 being affected, the breaking change seems to be something we uplifted (42.0 merged to aurora on 2015-08-10). I wonder if this could help us to narrow it down?

Comment 9

[Sebastian Kaspari (:sebastian; :pocmo)]

droeh: Are you working on this or should someone else look into it?

Comment 10

[Dylan Roeh (:droeh) (he/him)]

Sebastian, all my time at the moment is being spent on bug 1156817. I'll certainly take a look at this afterwards, but I'm not actively looking into it right now.

Comment 11

[James Willcox (:snorp) ([e-mail]) (he/him)]

Margaret, this looks like a frontend issue, can you assign someone else?

Comment 12

[:Margaret Leibovic]

(In reply to Sebastian Kaspari (:sebastian) from comment #8)
> This is about to slip into the 42.0 release!
> 
> I tried to bisect using the regression range but this is painful with the
> latest build changes on our side and google moving to SDK23 on their side. I
> downgraded my support library and used an old-style mozconfig but then it
> seems like my local google play services version is too advanced (back then
> we didn't use AARs). Unfortunately I can't downgrade it because I can't
> guess the download URL like I did with the 22 support library (The current
> URL is
> https://dl.google.com/android/repository/google_play_services_8115000_r27.
> zip but what's the URL for 7.8?)
> 
> Anyways, looking at the regression range (2015-08-27 - 2015-08-28) and 42.0
> being affected, the breaking change seems to be something we uplifted (42.0
> merged to aurora on 2015-08-10). I wonder if this could help us to narrow it
> down?

Bug 1009795 matches that criteria. From this changeset, it looks like this patch uses the ES 6 Intl API, which we don't ship on Android:
https://hg.mozilla.org/mozilla-central/rev/cb7008d63383#l1.19

Sebastian, could you try making a build with a backout of cb7008d63383, to see if that fixes the issue?

Ehsan, is there an alternate way to write that patch to not break Fennec?

Comment 13

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to :Margaret Leibovic from comment #12)
> Sebastian, could you try making a build with a backout of cb7008d63383, to
> see if that fixes the issue?

Yeah, I actually tried that last week. :) But I couldn't easily "unapply" the patch without conflicts. But I can see whether I can revert those changes manually.

> Ehsan, is there an alternate way to write that patch to not break Fennec?

It looks like the follow-up patch in Bug 1009795 does that and it's flagged with approval-mozilla-aurora+ so I assume it has been uplifted too. But I'll check.

Comment 14

[:Gijs (he/him)]

Pretty sure this is a dupe of the other dep of 1009795 that I just landed a fix for?

Comment 15

[:Gijs (he/him)]

That is: bug 1211255. It'd still be nice, as noted there, if we had a regression test for this on the fennec side. :-\

Comment 16

[:Margaret Leibovic]

(In reply to :Gijs Kruitbosch from comment #15)
> That is: bug 1211255. It'd still be nice, as noted there, if we had a
> regression test for this on the fennec side. :-\

Yes, this sounds like a dupe. Thanks for writing a patch for that!

And yes, it would be nice to have a regression test... we do have the ability to run different kinds of JS tests, maybe an xpcshell test could be designed to catch this?
https://wiki.mozilla.org/Mobile/Fennec/Android/Testing#xpcshell