46 bytes, text/x-github-pull-request
|Details | Review|
STR: * Flash new build * See FTU statusbar Actual: All empty I read the code and I believe using screen to toggle max/min statusbar is not a good idea. Too many rules to maintain. :(
Sounds like we need some tests here.
Alberto, please take a look thanks! The work you did(moving label icon outside other icons) makes sense to me but it's not ideal to use screen element to control the statusbar show/hide. It's easy to make mistake like this :(
Assignee: nobody → apastor
Comment on attachment 8540095 [details] [review] Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/26927 Totally agree. Actually, I'm not sure where those selectors came from, but probably somehow from legacy code, because those selectors are not needed anymore with the current approach. Now we are using only 1 statusbar that is always shown, but out of the screen. Every app has his own shadow (moz-element) and the color filters are applied there (including ftu, lockscreen and homescreen). That will help a lot on issues we had regarding icons colors and visibility. Also on the animation of the utility tray display. The only exception I added to the selectors is the cards view, as there is a test that checks exactly that (statusbar wrappers hidden in the cards view). I'm not sure if the intention of the test was hiding the statusbar only in the actual screen top, or the statusbar of every card. I'll file a new bug to tackle that. :alive, could you please review this? Don't hesitate to contact me if you have any question.
Attachment #8540095 - Flags: review?(alive)
This fails smoketests, adding keyword.
Comment on attachment 8540095 [details] [review] Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/26927 Thanks! For task manager I think we need to try if hide the statusbar does value. If that does (for perf reason maybe), we should update the visibility of statusbar via task-manager-shown/task-manager-hidden event instead of using screen element.
Attachment #8540095 - Flags: review?(alive) → review+
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
This issue is Verified Fixed in the latest Flame 3.0 and 2.2 builds. Status bar appears properly during the FTU. Environmental Variables: Device: Flame 3.0 (319MB)(Full Flash) Build ID: 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 (319MB)(Full Flash) Build ID: 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
QA Whiteboard: [QAnalyst-Triage?][fxosqa-auto-backlog+] → [QAnalyst-Triage+][fxosqa-auto-backlog+]
You need to log in before you can comment on or make changes to this bug.