Closed Bug 1201512 Opened 6 years ago Closed 6 years ago

Downloaded files not appearing in about:downloads until browser restart

Categories

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

ARM
Android
defect
Not set
normal

Tracking

(firefox40 unaffected, firefox41 unaffected, firefox42 affected, firefox43 affected, firefox44 affected, fennec42+)

RESOLVED DUPLICATE of bug 1211255
Tracking Status
firefox40 --- unaffected
firefox41 --- unaffected
firefox42 --- affected
firefox43 --- affected
firefox44 --- affected
fennec 42+ ---

People

(Reporter: cos_flaviu, Assigned: droeh)

References

Details

(Keywords: regression)

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.
The downloaded file appears in about:downloads only after browser restart.
Summary: Downloaded files not appearing in about:downloads → Downloaded files not appearing in about:downloads until browser restart
droeh, could this be related to the work for bug 1163937?
Flags: needinfo?(droeh)
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.
Flags: needinfo?(droeh)
Flaviu would you use mozregression to get regression range?
tracking-fennec: --- → ?
Flags: needinfo?(flaviu.cos)
Keywords: regression
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
Flags: needinfo?(flaviu.cos)
bug 1009795? Though a one day range is rather big, we should have inbound builds still.
Flags: needinfo?(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
Flags: needinfo?(flaviu.cos)
Assignee: nobody → droeh
Status: NEW → ASSIGNED
tracking-fennec: ? → 42+
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?
droeh: Are you working on this or should someone else look into it?
Flags: needinfo?(droeh)
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.
Flags: needinfo?(droeh)
Margaret, this looks like a frontend issue, can you assign someone else?
Flags: needinfo?(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?
Blocks: 1009795
Flags: needinfo?(s.kaspari)
Flags: needinfo?(margaret.leibovic)
Flags: needinfo?(ehsan)
(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.
Pretty sure this is a dupe of the other dep of 1009795 that I just landed a fix for?
That is: bug 1211255. It'd still be nice, as noted there, if we had a regression test for this on the fennec side. :-\
(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
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(s.kaspari)
Flags: needinfo?(ehsan)
Resolution: --- → DUPLICATE
Duplicate of bug: 1211255
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.