Closed Bug 1081402 Opened 5 years ago Closed 4 years ago

[Lockscreen] Difficult to open downloads from the lockscreen

Categories

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(b2g-v2.0 unaffected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED WONTFIX
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: rpribble, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: [2.2-Daily-Testing])

Attachments

(1 file)

Attached file Logcat.txt
Description:
Download notifications from the lockscreen are difficult to open. The notification refreshes constantly because of the climbing percentage, and the 'open' button flashes away before the user can tap it.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141010040202
2) Begin downloading a large file from the browser (1GB download used for test)
3) Lock the device 
4) Tap the download notification
5) Observe 'open' button flash once rapidly
  
Actual:
Download notifications are difficult to open from the lockscreen.
  
Expected: 
Download notifications allow the user adequate time to be able to tap the 'open' button.
  
Environmental Variables:
Device: Flame 2.2 Master KK (319 MB)
BuildID: 20141010040202
Gaia: 1036b544b7e102592bd9fab95cd9317329ac1293
Gecko: 50b689feab5f
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: v184
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
  
Notes:
  
Repro frequency: 100%
See attached: Video and logcat
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QAWanted for Branch Checks.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
Tested with Shallow Flash on 319mb using Engineering builds

This bug repro's on Flame KK builds: Flame 2.2 KK, Flame 2.1 KK

Actual Results: Tapping on the Downloading message on the Lockscreen, shows the user a quick glimpse of OPEN. The user can actually keep tapping the message and activate the OPEN command to bypass the unlock process and go to the Downloads section.

Repro Rate: 2/2

Environmental Variables:
Device: Flame Master KK
BuildID: 20141014064254
Gaia: de254419f3553f48187d003ee8e38034b429f069
Gecko: eb1b8ecbefde
Version: 36.0a1 (Master) 
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.1 KK
BuildID: 20141014082152
Gaia: c1fef90cdbb82410b0f3f7d9f76c4fd07a2623cc
Gecko: d89da458f88a
Version: 34.0 (2.1) 
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

-----------------------------------------------------------------
-----------------------------------------------------------------

This bug does NOT repro on Flame kk build: Flame 2.0 KK

Actual Result: Tapping the download in progress on the lock screen does not produce the OPEN message briefly. No affect to the user tapping.

Repro Rate: 0/2

Environmental Variables:
Device: Flame 2.0
BuildID: 20141014082253
Gaia: 21fc294d6c9b78997142153fc32c3175b4835a89
Gecko: 99387ed59305
Version: 32.0 (2.0) 
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawantedregression
QA Contact: croesch
NI to Download Manager owner for Blocking Decision
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(mozillamarcia.knous)
I wouldn't block on this issue. I would expect the user could wait until the large file finished downloading and then open it.
Flags: needinfo?(mozillamarcia.knous)
Mass update: Resolve wontfix all issues with legacy homescreens.

As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.
Blocks: 1231115
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.