Closed Bug 1071983 Opened 10 years ago Closed 10 years ago

[Status Bar] Swiping back to previous app removes the status bar icons

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S6 (10oct)
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: pbylenga, Assigned: yzen)

References

Details

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

Attachments

(2 files)

Attached image 2014-09-23-15-26-33.png (deleted) —
Description: Swiping away from current app and then back before the next app loads will remove the status bar icons. This occurs on JB and KK bases. Repro Steps: 1) Update a Flame to 20140922063004 2) Launch Calendar app 3) Return to homescreen and launch Settings App 4) Use edge gesture to go to Calendar app and before it loads swipe back to Settings App Actual: Settings app is restored but missing the status bar icons Expected: Settings app is restored and the status bar retains its icons Environmental Variables: Device: Flame v2.1 KK Build ID: 20140922063004 Gaia: 689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91 Gecko: 185fc54d29c1 Version: 34.0a2 (2.1) Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Repro frequency: (5/5, 100%) See attached: (screenshot,logcat)
QAWanted for Branch Checks
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Whiteboard: [2.1-Daily-Testing]
QA Contact: ckreinbring
The bug repros on Flame 2.2 and Flame 2.1 Actual result: If the user swipes to one app using edge gestures then quickly swipes to another app before the first app loads, the status bar will disappear. Flame 2.2 BuildID: 20140923065343 Gaia: 37b8a812c642ca616bf9457cb9b71e45261cdfa8 Gecko: 9e193395b912 Platform Version: 35.0a1 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Flame 2.1 BuildID: 20140923073140 Gaia: 1e554253d11b0cc932de39c0a4510d1abb176550 Gecko: ee9dbbb02910 Platform Version: 34.0a2 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 -------------------------------------------------------------------------------------------------------- The bug does not repro on Flame 2.0 Actual result: If the user swipes to one app using edge gestures then quickly swipes to another app before the first app loads, the status bar remains visible. BuildID: 20140923071344 Gaia: 6449cc35a8f0704d95acac374ba857bde4b86d6c Gecko: f18695cae418 Platform Version: 32.0 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
[Blocking Requested - why for this release]: regression, broken functionality in a major feature
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: ckreinbring
QA Contact: ckreinbring
Regression window Last working BuildID: 20140911062733 Gaia: 7f21bdda274f0329393ef0e5a9374c06255c6f57 Gecko: ef81f73048dc Platform Version: 35.0a1 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 First broken BuildID: 20140911063332 Gaia: e3b9d0d6516177636965d97c63c60981a24a0662 Gecko: 98ea98c8191a Platform Version: 35.0a1 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Working Gaia / Broken Gecko = No repro Gaia: 7f21bdda274f0329393ef0e5a9374c06255c6f57 Gecko: 98ea98c8191a Broken Gaia / Working Gecko = Repro Gaia: e3b9d0d6516177636965d97c63c60981a24a0662 Gecko: ef81f73048dc Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/7f21bdda274f0329393ef0e5a9374c06255c6f57...e3b9d0d6516177636965d97c63c60981a24a0662 Mozilla Inbound Last working BuildID: 20140910201328 Gaia: 6a533b800e1fa794013887761e62dd4f4d34cea1 Gecko: 65052f412002 Platform Version: 35.0a1 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 First broken BuildID: 20140910205727 Gaia: 7c5014a7b040c526022126c4db09a8f065aa4275 Gecko: b2edbcf0da31 Platform Version: 35.0a1 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Working Gaia / Broken Gecko = No repro Gaia: 6a533b800e1fa794013887761e62dd4f4d34cea1 Gecko: b2edbcf0da31 Broken Gaia / Working Gecko = Repro Gaia: 7c5014a7b040c526022126c4db09a8f065aa4275 Gecko: 65052f412002 Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/6a533b800e1fa794013887761e62dd4f4d34cea1...7c5014a7b040c526022126c4db09a8f065aa4275
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Broken by Bug 1045017? Can you take a look Yura?
Blocks: 1045017
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(yzenevich)
Assignee: nobody → yzenevich
Status: NEW → ASSIGNED
Flags: needinfo?(yzenevich)
Attached file Github pull request. (deleted) —
Attachment #8495437 - Flags: review?(kgrandon)
Comment on attachment 8495437 [details] Github pull request. Since Alive reviewed bug 1045017 which caused this, and it's a little bit more complex, I think that he should review this as well. My personal thoughts are that I don't think we should need a stackunchanged event. If we need this, it seems like we might have a race condition somewhere, or we're missing a clearTimeout() perhaps. I'm not sure if you've done the investigation, but if you have any ideas as to why please clarify.
Attachment #8495437 - Flags: review?(kgrandon) → review?(alive)
(In reply to Kevin Grandon :kgrandon from comment #7) > Comment on attachment 8495437 [details] > Github pull request. > > Since Alive reviewed bug 1045017 which caused this, and it's a little bit > more complex, I think that he should review this as well. > > My personal thoughts are that I don't think we should need a stackunchanged > event. If we need this, it seems like we might have a race condition > somewhere, or we're missing a clearTimeout() perhaps. I'm not sure if you've > done the investigation, but if you have any ideas as to why please clarify. So as far as I understood, there's nothing to indicate we are back to the staring app, except the lack of stackchanged event. Having something in StackManager's _broadcast (where we check already if we are back to to the same place) doesn't help much either, since it happens after a delay because broadcasting was queued.
Comment on attachment 8495437 [details] Github pull request. It looks to me the problem is we hide the statubar on sheet-transition-start but didn't take it back. That is introduced by bug 1044125. I am not sure why we do that, but IMO we don't need a stachunchanged event, too. We should * Find out why need to hide statusbar on sheet transition start. * If we do need, find a proper event
Attachment #8495437 - Flags: review?(alive) → review?(etienne)
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #9) > Comment on attachment 8495437 [details] > Github pull request. > > It looks to me the problem is we hide the statubar on sheet-transition-start > but didn't take it back. That is introduced by bug 1044125. I am not sure > why we do that, but IMO we don't need a stachunchanged event, too. We should > * Find out why need to hide statusbar on sheet transition start. > * If we do need, find a proper event Status bar needs to be hidden on sheets-gesture-begin because it will otherwise overlap with the one from the app (or rather its screenshot) that is being swiped in.
Comment on attachment 8495437 [details] Github pull request. Yep we should use |sheets-gesture-end| for that. In comes after a delay, so following the STR of this bug the icons would disappear then reappear right after. We can trigger the |sheets-gesture-end| earlier in this case to prevent the flash, but we need to make sure we're only dispatching it once.
Attachment #8495437 - Flags: review?(etienne) → review-
Comment on attachment 8495437 [details] Github pull request. Updated based on comments, IRC convo.
Attachment #8495437 - Flags: review- → review?(etienne)
Comment on attachment 8495437 [details] Github pull request. r=me with the small comments on github addressed
Attachment #8495437 - Flags: review?(etienne) → review+
Whiteboard: [2.1-Daily-Testing] → [2.1-Daily-Testing] [systemsfe]
Bad regression
blocking-b2g: 2.1? → 2.1+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to Yura Zenevich [:yzen] from comment #15) > https://github.com/mozilla-b2g/gaia/commit/ > a7b0b82a0c3a5ced14c4655cd9b43c7cfd88c100 Yura, can you ask for uplift approval please?
Flags: needinfo?(yzenevich)
Comment on attachment 8495437 [details] Github pull request. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): Bug 1045017 [User impact] if declined: Status bar is going to be broken when swiping between apps. [Testing completed]: Added necessary unit tests, manual testing. [Risk to taking this patch] (and alternatives if risky): Medium. There are some changes to the JS. [String changes made]: none
Attachment #8495437 - Flags: approval-gaia-v2.1?
Flags: needinfo?(yzenevich)
Attachment #8495437 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
Depends on: 1081741
Bug: 1081741 has been written, since this bug has failed verification
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Whiteboard: [2.1-Daily-Testing] [systemsfe] → [2.1-Daily-Testing] [systemsfe][failed-verification]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
Whiteboard: [2.1-Daily-Testing] [systemsfe][failed-verification] → [2.1-Daily-Testing] [systemsfe]
This issue still repros on Flame 2.1 and Flame 2.2 Flame 2.1 Device: Flame 2.1 KK (319mb) (Full Flash) BuildID: 20141013001201 Gaia: d18e130216cd3960cd327179364d9f71e42debda Gecko: 610ee0e6a776 Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Flame 2.2 Device: Flame 2.2 Master KK (319mb) (Full Flash) BuildID: 20141013040202 Gaia: 3b81896f04a02697e615fa5390086bd5ecfed84f Gecko: f547cf19d104 Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Actual: Settings app is restored but missing the status bar icons
Status: RESOLVED → VERIFIED
Status: VERIFIED → RESOLVED
Closed: 10 years ago10 years ago
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
There might have been another regression that caused this bug to resurface. Not sure. Yura, can you take a look?
Flags: needinfo?(yzenevich)
I'll take a look, thanks
Flags: needinfo?(yzenevich)
qawanted to see if this is still reproducible on 2.1 and master.
Keywords: qawanted
I can no longer reproduce this issue on the latest 2.2 Flame KK and 2.1 Flame KK builds Environmental Variables: Device: Flame 2.2 Shallow Flash BuildID: 20141106045123 Gaia: 068b9711277b06c7d633517f9e1fcb5624bb39b3 Gecko: 0c66a9fd9085 Version: 36.0a1 (2.2) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Environmental Variables: Device: Flame 2.1 Shallow Flash BuildID: 20141106124620 Gaia: aa63911ae979ed1e3eab2ba23a6e7d6a59085854 Gecko: 036fc27e6523 Version: 34.0 (2.1) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage?][failed-verification]
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Contact: ckreinbring
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: