Closed Bug 1162284 Opened 9 years ago Closed 9 years ago

[Window Management] Status bar briefly displays bolded icons and time when reopening an app

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.5+, b2g-v2.1 affected, b2g-v2.2 affected, b2g-master verified)

VERIFIED FIXED
FxOS-S1 (26Jun)
blocking-b2g 2.5+
Tracking Status
b2g-v2.1 --- affected
b2g-v2.2 --- affected
b2g-master --- verified

People

(Reporter: pcheng, Assigned: yzen)

References

Details

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

Attachments

(2 files)

Attached image screenshots.png
Description:
When re-opening an app, often times the status bar will display bolded icons and time for the duration of re-initializing the app.

STR:
0) Have some icons on status bar; observe what they normally look like
1) Open Settings and Clock app
2) Go back to Settings, observe status bar when opening
3) If bug doesn't repro, switch between Clock and Settings, and observe the status bar opening them

Expected: Shape of status bar icons and time remain unchanged under all circumstances

Actual: Status bar displays icons and time as bolded for ~2 seconds when reloading an app.

See attached screenshot for comparison. This issue is too difficult to capture on a video.

Repro rate: 7 out of 10

Device: Flame (KK, full flashed, 319MB)
BuildID: 20150506010204
Gaia: 3e6fd1e0a478af2c95d09ce95c2c6de2de2fec14
Gecko: ba44099cbd07
Gonk: a9f3f8fb8b0844724de32426b7bcc4e6dc4fa2ed
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0
This issue also reproduces on Flame 2.2, but it happens much less frequently and it recovers to normal quicker too. When it happens it is there for a fraction of a second which I'll call it as a not reproducible.

Device: Flame 2.2
BuildID: 20150506002501
Gaia: 772a9491909abd02dc67278dd453746e2dd358a8
Gecko: 3af6a0a79227
Gonk: ab265fb203390c70b8f2a054f38cf4b2f2dad70a
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regression
Whiteboard: [3.0-Daily-Testing]
blocking-b2g: --- → 3.0+
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][systemsfe]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
QA Contact: pcheng
This bug is easier to reproduce on shallow flash. On shallow flash this bug is reproducible on v2.2 and v2.1 (not applicable in v2.0 because status bar stays intact with apps and doesn't get re-drawn). But on full flash it can only be reliably reproduced on v3.0.

This looks like a bug that's happening in conjunction with low memory, but low memory isn't the cause. I'll try and see if I can find a window in shallow flashing.
Marking tracking flags based on shallow flash results. Note that v2.0 is not marked because its status bar is isolated from all the apps.
b2g-inbound regression window:

Last Working
Device: Flame
BuildID: 20140910201328
Gaia: 6a533b800e1fa794013887761e62dd4f4d34cea1
Gecko: 65052f412002
Version: 35.0a1 (2.2 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

First Broken
Device: Flame
BuildID: 20140910205727
Gaia: 7c5014a7b040c526022126c4db09a8f065aa4275
Gecko: b2edbcf0da31
Version: 35.0a1 (2.2 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Last Working Gaia First Broken Gecko - issue does NOT repro
Gaia: 6a533b800e1fa794013887761e62dd4f4d34cea1
Gecko: b2edbcf0da31

Last Working Gecko First Broken Gaia - issue DOES repro
Gaia: 7c5014a7b040c526022126c4db09a8f065aa4275
Gecko: 65052f412002

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/6a533b800e1fa794013887761e62dd4f4d34cea1...7c5014a7b040c526022126c4db09a8f065aa4275

Possibly caused by Bug 1045017.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Yura, can you take a look at this please? Looks like the work done for bug 1045017 might have caused this.
Blocks: 1045017
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(yzenevich)
Can't seem to notice the issue. Maybe I am looking at the statusbar at the wrong time. Do you see the issue when the overlay is removed after edge-gesturing to the app or when it is still on? I am also assuming it happens in any app with visible statusbar ?
Flags: needinfo?(yzenevich) → needinfo?(pcheng)
Not sure about what the overlay part is? I'm not edge gesturing, just re-opening an app. I'll try to get a video of the issue, although I doubt it's gonna be noticeable in video. Keeping NI.
Please look at the video.

http://youtu.be/dtixODgJ5v8

In the beginning of the video I have Phone app in the foreground showing how status bar normally looks like. Then I go back to Homescreen and bring Settings app to foreground, and it's during that opening of Settings it shows bolded status bar icons and time for about 1 to 2 seconds, followed by Settings app finally showing contents.

I let the video display in landscape so it's easier to see.
Flags: needinfo?(pcheng) → needinfo?(yzenevich)
Assignee: nobody → yzenevich
Attached file Github pull request.
Would you be able to see if this PR fixes the issue?
Flags: needinfo?(yzenevich)
Attachment #8614838 - Flags: feedback?
Comment on attachment 8614838 [details] [review]
Github pull request.

^
Attachment #8614838 - Flags: feedback? → feedback?(pcheng)
Comment on attachment 8614838 [details] [review]
Github pull request.

Issue still reproduces after applying the patch. Patch was applied on today's 3.0 nightly.

Were you able to repro the bug locally? Is there anything else I can help you reproducing the bug? It should be fairly easy to reproduce. I've been on 319MB Flame, it could be easier to encounter with that memory setting.
Flags: needinfo?(yzenevich)
Attachment #8614838 - Flags: feedback?(pcheng) → feedback-
Comment on attachment 8614838 [details] [review]
Github pull request.

This version seems to work better on my device, would you be able to take a look? Thanks!
Flags: needinfo?(yzenevich)
Attachment #8614838 - Flags: feedback- → feedback?(pcheng)
Comment on attachment 8614838 [details] [review]
Github pull request.

This is better. After patch, repro rate seems much lower, and when it happens in 1 out of ~20 attempts, the duration of issue happens shorter than original issue. I'd call this a pass.

Tested patch on top of today's 3.0 nightly user build.
Flags: needinfo?(yzenevich)
Attachment #8614838 - Flags: feedback?(pcheng) → feedback+
Comment on attachment 8614838 [details] [review]
Github pull request.

'stackchanged' seems to negate the logic of hidden/unhidden statusbar as it fires to soon after the statusbar is hidden. Also ensuring that the statusbar shadow is only visible when the statusbar is hidden.
Flags: needinfo?(yzenevich)
Attachment #8614838 - Flags: review?(mhenretty)
Ah I see, it's displaying statusbar and statusbar shadow together. Good catch guys.

Still, let's wait and see if bug 1172867 improves the situation first, and then rebase this on top of that. The code changes are very similar, and I think we should land that one first.
Depends on: 1172867
(In reply to Michael Henretty [:mhenretty] from comment #15)
> Ah I see, it's displaying statusbar and statusbar shadow together. Good
> catch guys.
> 
> Still, let's wait and see if bug 1172867 improves the situation first, and
> then rebase this on top of that. The code changes are very similar, and I
> think we should land that one first.

Sounds good, thanks Michael.
Could you see if the latest master resolves this issue, I think the PR that Michael mentioned is merged now.
Flags: needinfo?(pcheng)
This issue appears to be fixed on Flame 3.0. Marking bug as fixed. Bug 1172867 seems to have caused a regression though.

Device: Flame (KK, full flashed, 319MB)
BuildID: 20150619010205
Gaia: a0df9c367a68764bdcf2e2e1c4d27f0d6ee165b8
Gecko: 2694ff2ace6a
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 41.0a1 (3.0 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(pcheng)
Resolution: --- → FIXED
Comment on attachment 8614838 [details] [review]
Github pull request.

removing r?
Attachment #8614838 - Flags: review?(mhenretty)
This issue is verified fixed on the latest Nightly Flame 2.5 build.

Actual Results: The status bar icons and numbers do not bold when entering an app and is the correct color now that the regressions from bug 1172867 have been fixed.

Environmental Variables:
Device: Flame 2.5 KK (319 MB) (Full Flash)
BuildID: 20150629010206
Gaia: 8a1e4ae522c121c5cacd39b20a5386ec9055db82
Gecko: eaf4f9b45117
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 41.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Target Milestone: --- → FxOS-S1 (26Jun)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: