Status Bar icons flashing during expanded/collapsed rocketbar transition

VERIFIED FIXED in 2.2 S5 (6feb)

Status

defect
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: gwagner, Assigned: apastor)

Tracking

({regression})

unspecified
2.2 S5 (6feb)
x86
macOS

Firefox Tracking Flags

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

Details

(Whiteboard: [systemsfe])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

4 years ago
All the status bar icons disappear and it takes too long to display them again.
(Reporter)

Updated

4 years ago
blocking-b2g: --- → 2.2+
Whiteboard: [systemsfe]
I'm not seeing this with an older build, so adding qawanted first for branch checks.
Keywords: qawanted
I can *sort of* reproduce this bug but will need confirmation from original reporter on bug behavior.

Reporter, please see the following video and verify if this is the bug you're referring to.

http://youtu.be/zzm49_pzF7E

It's a bit difficult to record on video but it shows a very brief (fraction of a second) disappearance of status bar after closing the Rocketbar while inside in app.

Tested on:
Device: Flame 2.2 Master (shallow flash, 319MB mem)
BuildID: 20150105033341
Gaia: 4ceeff19086b2a2955f044ad923dcfa63a293de3
Gecko: 912036eeb024
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Flags: needinfo?(anygregor)
(Reporter)

Comment 3

4 years ago
(In reply to Pi Wei Cheng [:piwei] from comment #2)
> I can *sort of* reproduce this bug but will need confirmation from original
> reporter on bug behavior.
> 
> Reporter, please see the following video and verify if this is the bug
> you're referring to.
> 
> http://youtu.be/zzm49_pzF7E
> 

I am talking about the flashing during the transition from expanded to collapsed rocketbar.
https://www.youtube.com/watch?v=NT9yIZRsBj4&feature=youtu.be
Flags: needinfo?(anygregor)
(Reporter)

Comment 4

4 years ago
Even better to see when opening a bookmark:
https://www.youtube.com/watch?v=7IHEvu-s-q0&feature=youtu.be
QA Contact: pcheng
A video really helps in visualizing/reproducing the issue. I can reproduce this on 2.2 with the same build as comment 2. Status bar icons redraw every time user pulls up (minimizes) the address bar while browsing yelp app or opening a bookmark.

-----------

This issue does not continuously reproduce on Flame 2.1. The flashing of status bar icons only occurs on first attempt of pulling up the address bar. Status bar icons remain static and does not redraw on all subsequent attempts within the same browsing session. So I'm going to call this a no repro, or at least less severe/noticeable than 2.2.

Device: Flame 2.1 (shallow flash)
BuildID: 20150105144122
Gaia: b04a8cb7b2482e0a44e6702b48c42283a00b5b1e
Gecko: 99cea2c818f6
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

----

The ability to pull down the address bar/rocketbar while browsing is NOT available in Flame 2.0. Not setting tracking flag because the feature is not present.

Device: Flame 2.0 (shallow flash)
BuildID: 20150106031641
Gaia: f76014fd2c7528493b90d759c68ec3070233d094
Gecko: df601187a23a
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawantedregression
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+]
QA Contact: pcheng → jmercado
B2g-inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141013204756
Gaia: ec355e1c02ebffbfda778661c2501a0bc78317dc
Gecko: b6e9b4bc9630
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141013213259
Gaia: 711daa290264a1ad9a7708fccca05f41d5482a49
Gecko: 8f2d3858d2b3
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Last Working gaia / First Broken gecko - Issue does NOT occur
Gaia: ec355e1c02ebffbfda778661c2501a0bc78317dc
Gecko: 8f2d3858d2b3

First Broken gaia / Last Working gecko - Issue DOES occur
Gaia: 711daa290264a1ad9a7708fccca05f41d5482a49
Gecko: b6e9b4bc9630

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/ec355e1c02ebffbfda778661c2501a0bc78317dc...711daa290264a1ad9a7708fccca05f41d5482a49
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
The fix for Bug 1074028 seems to have caused this issue.
Guillaume, can you please take a look at this issue? It appears the uplift for bug 1074028 may have caused this to occur.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(gmarty)
It seems like I wrote the patch for bug 1074028. I'll try to take a look here time permitting.
Flags: needinfo?(gmarty) → needinfo?(kgrandon)
Either the regression window or the branch status is wrong here. Bug 1074028 was included in 2.1, so if that's causing the regression, it should also be in 2.1.
Flags: needinfo?(kgrandon)
Piwei's comment 5 does mention that 2.1 is affected, just much less noticible.
(Assignee)

Comment 12

4 years ago
I'm going to start taking a look.
Assignee: nobody → apastor
(Assignee)

Updated

4 years ago
Attachment #8555413 - Attachment is obsolete: true
(Assignee)

Comment 15

4 years ago
Comment on attachment 8555412 [details] [review]
[PullReq] albertopq:1118025-rocketbar-icons-transition to mozilla-b2g:master

We calculate the classes for each statusbar (minimized and maximized) even when hidden. When the chrome is maximized, the remaining space for the minimized statusbar is smaller (given that the search input takes almost the whole width), so when we show it we first see only 2 icons (the space we had before collapsing) and then the rest after the chrome gets collapsed.

The fix is avoiding updating the minimizedStatusbarWidth when the chrome is expanded, and only doing it when gets collapsed. That will solve most of cases, as the current and previous width will be the same.

Before adding tests, I would like to hear gamarty's feedback here, as he knows the code better than I do.
Attachment #8555412 - Flags: feedback?(gmarty)
Comment on attachment 8555412 [details] [review]
[PullReq] albertopq:1118025-rocketbar-icons-transition to mozilla-b2g:master

It looks good to me. Happy we finally get rid of this bug!
Attachment #8555412 - Flags: feedback?(gmarty) → feedback+
(Assignee)

Comment 17

4 years ago
Comment on attachment 8555412 [details] [review]
[PullReq] albertopq:1118025-rocketbar-icons-transition to mozilla-b2g:master

Ready for review! :)
Attachment #8555412 - Flags: review?(gmarty)
Comment on attachment 8555412 [details] [review]
[PullReq] albertopq:1118025-rocketbar-icons-transition to mozilla-b2g:master

Great job!
Attachment #8555412 - Flags: review?(gmarty) → review+
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.
Comment hidden (obsolete)
Comment on attachment 8555412 [details] [review]
[PullReq] albertopq:1118025-rocketbar-icons-transition to mozilla-b2g:master

Need a review from a suggested reviewer for autolander. I'll go ahead and leave an R+ here in case you want to try it again. (It looks like the patch needs to be rebased against master though)
Attachment #8555412 - Flags: review+
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Comment on attachment 8555412 [details] [review]
[PullReq] albertopq:1118025-rocketbar-icons-transition to mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
Bug 1074028 

[User impact] if declined:
Poor UX when expanding and collapsing the rocketbar, which is a common use case.

[Testing completed]:
Manual testing and added unit tests.

[Risk to taking this patch] (and alternatives if risky):
The risk is to the minimized rocketbar icons and how often they update. Now we perform more incremental calculations under certain situations.

[String changes made]: none.
Attachment #8555412 - Flags: approval-gaia-v2.2?
Attachment #8555412 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
This issue is fixed on the latest Nightly Flame 3.0 and Flame 2.2 builds.

Results:  The Status bar icons do not redraw when the rocketbar enters the status bar.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150206010204
Gaia: 94af4b42d2ace6c9f38f31de77240604fac68af1
Gecko: 7c5f187b65bf
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0


Environmental Variables:
Device: Flame 2.2
BuildID: 20150206002505
Gaia: a52999ce7f783177deb17e267bf003a53e6fde06
Gecko: 01446d5231ef
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.