Closed
Bug 1162284
Opened 10 years ago
Closed 10 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)
Tracking
(blocking-b2g:2.5+, 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)
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
Reporter | ||
Comment 1•10 years ago
|
||
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?]
status-b2g-v2.2:
--- → unaffected
status-b2g-master:
--- → affected
Flags: needinfo?(ktucker)
Keywords: regression
Whiteboard: [3.0-Daily-Testing]
Updated•10 years ago
|
blocking-b2g: --- → 3.0+
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][systemsfe]
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Reporter | ||
Updated•10 years ago
|
QA Contact: pcheng
Reporter | ||
Comment 2•10 years ago
|
||
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.
Reporter | ||
Comment 3•10 years ago
|
||
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.
status-b2g-v2.1:
--- → affected
Reporter | ||
Comment 4•10 years ago
|
||
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)
Keywords: regressionwindow-wanted
Comment 5•10 years ago
|
||
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)
Assignee | ||
Comment 6•10 years ago
|
||
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)
Reporter | ||
Comment 7•10 years ago
|
||
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.
Reporter | ||
Comment 8•10 years ago
|
||
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)
Updated•10 years ago
|
Assignee: nobody → yzenevich
Assignee | ||
Comment 9•10 years ago
|
||
Would you be able to see if this PR fixes the issue?
Flags: needinfo?(yzenevich)
Attachment #8614838 -
Flags: feedback?
Assignee | ||
Comment 10•10 years ago
|
||
Comment on attachment 8614838 [details] [review]
Github pull request.
^
Attachment #8614838 -
Flags: feedback? → feedback?(pcheng)
Reporter | ||
Comment 11•10 years ago
|
||
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-
Assignee | ||
Comment 12•10 years ago
|
||
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)
Reporter | ||
Comment 13•10 years ago
|
||
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+
Assignee | ||
Comment 14•10 years ago
|
||
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)
Comment 15•10 years ago
|
||
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
Assignee | ||
Comment 16•10 years ago
|
||
(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.
Assignee | ||
Comment 17•10 years ago
|
||
Could you see if the latest master resolves this issue, I think the PR that Michael mentioned is merged now.
Flags: needinfo?(pcheng)
Reporter | ||
Comment 18•10 years ago
|
||
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: 10 years ago
Flags: needinfo?(pcheng)
Resolution: --- → FIXED
Assignee | ||
Comment 19•10 years ago
|
||
Comment on attachment 8614838 [details] [review]
Github pull request.
removing r?
Attachment #8614838 -
Flags: review?(mhenretty)
Comment 20•10 years ago
|
||
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)
Updated•10 years ago
|
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Updated•10 years ago
|
status-b2g-v2.5:
--- → verified
Target Milestone: --- → FxOS-S1 (26Jun)
Updated•10 years ago
|
status-b2g-v2.5:
verified → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•