Confirmed users
478
edits
User:Timdream/Blocking Features: Difference between revisions
Jump to navigation
Jump to search
User:Timdream/Blocking Features (view source)
Revision as of 15:53, 28 January 2015
, 28 January 2015+ console.log issue
(+ console.log issue) |
|||
| Line 8: | Line 8: | ||
* '''Status:''' '''<font color=red>NOT STARTED</font>''' | * '''Status:''' '''<font color=red>NOT STARTED</font>''' | ||
* '''What is being blocked:''' | |||
* '''What this bug will solve:''' | * '''What this bug will solve:''' | ||
| Line 13: | Line 14: | ||
* '''Status:''' '''<font color=red>NOT STARTED</font>''' | * '''Status:''' '''<font color=red>NOT STARTED</font>''' | ||
* '''What is being blocked:''' | |||
* '''What this bug will solve:''' | * '''What this bug will solve:''' | ||
| Line 23: | Line 25: | ||
* '''Status:''' '''<font color=red>NOT STARTED</font>''' | * '''Status:''' '''<font color=red>NOT STARTED</font>''' | ||
* '''What is being blocked:''' Incorrect orientation of lock screen/system UI with an easy-to-produce STR, consistently being nominated as blockers by partners in multiple previous versions. | |||
* '''What this bug will solve''': By allowing System app to take part of deciding whether or not to allow a given app to lock the orientation, we will be able to block orientation lock happens right at the time app goes to background. | * '''What this bug will solve''': By allowing System app to take part of deciding whether or not to allow a given app to lock the orientation, we will be able to block orientation lock happens right at the time app goes to background. | ||
| Line 28: | Line 31: | ||
* '''Status:''' on going, see <<insert update page here>> | * '''Status:''' on going, see <<insert update page here>> | ||
* '''What is being blocked:''' | |||
* '''What this bug will solve''': | * '''What this bug will solve''': | ||
| Line 38: | Line 42: | ||
* '''Status:''' ? | * '''Status:''' ? | ||
* '''What is being blocked:''' Performance issues involving mozApp.getAll() calls during start-up. | |||
* '''What this bug solves:''' | * '''What this bug solves:''' | ||
| Line 43: | Line 48: | ||
* '''Status:''' ? | * '''Status:''' ? | ||
* '''What is being blocked:''' | |||
* '''What this bug solves:''' | * '''What this bug solves:''' | ||
| Line 48: | Line 54: | ||
* '''Status:''' ? | * '''Status:''' ? | ||
* '''What is being blocked:''' | |||
* '''What this bug solves:''' (is this bug really had blocked any blockers?) | * '''What this bug solves:''' (is this bug really had blocked any blockers?) | ||
| Line 53: | Line 60: | ||
* '''Status:''' '''<font color=red>NOT STARTED</font>''' | * '''Status:''' '''<font color=red>NOT STARTED</font>''' | ||
* '''What is being blocked:''' Performance issues that could be blockers in the next release. | |||
* '''What this bug will solve:''' The DB_VERSION of mozSettings is hidden inside Gecko, therefore to upgrade a settings in Gaia we would have to read the setting every time the phone boots or the app start ups. This contributes to boot time a lot and we are very close being asked to block a release for this (see the depending bugs of that bug). We would either have to patch Gecko to put all the migration there or we would have to expose something non-trivial to Gaia instead. | * '''What this bug will solve:''' The DB_VERSION of mozSettings is hidden inside Gecko, therefore to upgrade a settings in Gaia we would have to read the setting every time the phone boots or the app start ups. This contributes to boot time a lot and we are very close being asked to block a release for this (see the depending bugs of that bug). We would either have to patch Gecko to put all the migration there or we would have to expose something non-trivial to Gaia instead. | ||
== Unlock Console API for Gaia: {{bug|1066581}} == | |||
* '''Status:''' '''<font color=red>NOT STARTED</font>''' | |||
* '''What is being blocked:''' Lot's of previous MTBF bugs. | |||
* '''What this bug will solve:''' From time to time, we are asked to debug '''MTBF''' issues with log. Currently, we have always have to work submit a patch with lines-to-print and ask QA engineers to re-run, instead of having these logging check into the tree. According to measurement in the bug, adding console.log() will slow down main thread significantly. '''There has been time where racing bugs simply unreproducible when the log was added as well'''. The fix proposed here is to make logging faster, at least not noticeable until it's turned on from Gecko. Our logger in apps, currently, unfortunately, have to wire their own logging to a app script with it's own, special switch. | |||