Created attachment 8517649 [details] log1105.txt Description: When tapping a downloading file from notification, the user is navigated to "Settings" first and then to "Downloads" Repro Steps: 1) Update a Flame device to BuildID: 20141105001204 2) Start a download (https://owd.tid.es/dm/) 3) Swipe to open notification tray 4) Tap a downloading file Actual: The "Downloads" page is takes too long to open it opens "Settings" first and then navigates to the "Download" page" Expected: When tapping the downloading file, the user is navigated straight to the "Dow Device: Flame 2.1 KK BuildID: 20141105001204 Gaia: 154da5e17029a51002d5d9b7df39563d509edde6 Gecko: 3b0c3580a58d Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 34.0 (2.1) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Repro frequency: 100% See attached: logcat, video
The issue DOES NOT repro on 2.2 and 2.0 Flame Device: Flame 2.2 Master KK BuildID: 20141112040208 Gaia: 5ae28ff11b982e2bd7d1aa097cda131536952bdc Gecko: 688f821edcd4 Version: 36.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Device: Flame 2.0 KK BuildID: 20141112000204 Gaia: ab83632c92f9fc571b11d8468b6901cc4ed905c0 Gecko: 1ff99565be67 Version: 32.0 (2.0) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Additional info to Comment 1, the issue reproduces on 2.1 Full Flash and Shallow Flash Actual Result: Transition is not smooth. The user is navigated to the "Settings" first" Expected Result: When tapping the downloading file, the user is navigated straight to the "Downloads" Flame 2.1 Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow/Full Flash) BuildID: 20141113001200 Gaia: 569a299ca446f714cd98d5881cc058fd6f6e257b Gecko: d188e92aa5a6 Version: 34.0 (2.1) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
[Blocking Requested - why for this release]: Nominating this to block 2.1. The transition is incorrect, very sluggish, and a regression.
Seems like we looked at a similar bug one or 2 weeks ago. Aus, Kevin, do you remember?
I feel like I saw this come and go in 2.2... Could we get a reverse regression window? in 2.2? That should enlighten us as to which commit magically fixed it in 2.2 :)
Don't know off the top of my head, but let's see if we can get a reverse regression window.
b2g-inbound reverse regression window: Last Broken Environmental Variables: Device: Flame BuildID: 20141020205719 Gaia: e09e1734ad523cf63351a28f6f84454319349fbe Gecko: 4da1f6a151d6 Version: 36.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 First Working Environmental Variables: Device: Flame BuildID: 20141020214218 Gaia: ba10744d64411a8a12ae68f7cf1ec3e3ac897d21 Gecko: bcc5df613d83 Version: 36.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Last Broken Gaia First Working Gecko - issue DOES repro Gaia: e09e1734ad523cf63351a28f6f84454319349fbe Gecko: bcc5df613d83 Last Broken Gecko First Working Gaia - issue does NOT repro Gaia: ba10744d64411a8a12ae68f7cf1ec3e3ac897d21 Gecko: 4da1f6a151d6 Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/e09e1734ad523cf63351a28f6f84454319349fbe...ba10744d64411a8a12ae68f7cf1ec3e3ac897d21 Fixed by Bug 1007600.
Fixed by Bug 1007600 - Arthur- can you take a look. Your patch fixed THIS issue in 2.2 but 2.1 is still affected.
The transition was because we were using window disposition. Switching to inline disposition is a new feature for v2.2 so it is not going to be uplifted to v2.1 unless there are strong requests.
Kevin, Aus; Please see comment 9. We can either 'make some noise' on this one or close it as won't fix.
It's all about the risk/reward ratio and in this case, I would say the risk of uplifting to 2.1 may not be worth the potential downfall. The feature itself that fixes this issue was slated for 2.2 only as well. That being said, the transition is kind of nasty, but I don't believe that it matches our blocking criteria.
(In reply to Joshua Mitchell [:Joshua_M] from comment #10) > Kevin, Aus; Please see comment 9. We can either 'make some noise' on this > one or close it as won't fix. I think we should close this bug, as I also don't think it fits the definition of a blocker, and it's highly unlikely that we'd get uplift approval on the settings patch. I think a "duplicate" of the settings feature is probably the best bet, but since we can't find that, I think a "worksforme" will be fine here since it's working in master. Feel free to change this though if it matters.