User:Timdream/Blocking Features

From MozillaWiki
Jump to: navigation, search

Gecko features blocking Gaia Blockers

The goal of this page is to collect wanted Gecko features that could fix blockers that cannot be fixed in Gaia apps along. We will try to use this list as a source when prioritize FxOS Gecko works (no, there are no promises, unfortunately -- but someone has to collect the list first).

IMPORTANT: To prevent this become a platform feature wish list, please only list a bug if it, or any bug that has any depend on it, has been nominated as a blocker.

P1

Visibility API update: bug 1034001

  • Status: Plan realigned in bug 1154231 and fixed, need to remove workarounds
  • Implication to v3: Unless we disallow users from switching between apps, issues will be valid for v3.
  • What this bug will solve: All issues with incorrect visibility state while doing app transitioning.
    • Bug 1124944 - [KK][Camera] Enabling Flash in Video Camera app then navigating away has flash remain on for several seconds
    • See blockers.

Orientation API update: bug 1043102, aka Skate Jumper bug

  • Status: :wchen is working on it.
  • Implication to v3: Issue is valid unless we disallow orientation change & switching apps
  • 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.

Audio Channel API update: bug 1089539

  • Status: on going, spec - bug 961967, gecko - bug 1113086, gaia - bug 1100822.
  • Implication to v3: Issue is valid unless we never have multiple sound sources.
  • What is being blocked: The current gecko audio channel management introduced bugs on audio competing and leaking, these kind of bugs are being blocked and we need this new api to fix them.
  • What this bug will solve: From v1.0 we introduced the audio channel management in gecko to handle the audio rules and policies, it works on 70% cases but for the other 30%(mostly are the audio competing issues) we couldn't fix them and instead we need to use workarounds. So to fix the audio channel issues entirely and make things right, the new audio channel api will have a new architecture and gaia system app will use them to control the app audio channels, base on the information from the channel's priorities and the window management.

Activity OOM priority: bug 1144132

  • Status: Gabriele Svelto take the platform fix and on m-c and targeting v2.2. He will provides gaia patch as well.

For v2.2 the plan is to workaround it by associating activity opener and openee together, For v3 the plan is to let system app controls the priority.

  • Implication to v3: Issue is valid unless we move away from inline activities.
  • What is being blocked: We have a old workaround in System app -- we never set an activity callee as invisible when it is covered by the activity caller, in fear that it could be OOM'ed. In turn, app could not know visibilitychange when there is an activity opened.
  • What this bug will solve: Any issue with incorrect document.hidden state in this situration, for example:
    • bug 1102675 - [Camera] black screen when open camera after open camera pick activity via camera
      • This is caused by the fact there are two camera instances in the phone and the previous one will not know it need to release the hardware.
    • bug 1072874 - [Video]Video Share through SMS/BT doesn't pause video
      • Video app does not stop playing since visibilitychange doesn't fire.

System message target: bug 931339

  • Status: NOT STARTED
  • Implication to v3: Issue is valid unless we move away from inline activities.
  • What is being blocked: The current impl of system message assume there is only one instance (frame) per app, so it only deliver the message to an attached handling callback once. If there is an activity being opened twice from difference source, only the first activity will catch the system message. That is to say, the second activity and so on will become malfunction totally.
  • What this bug will solve:
    • Cicular activities like: bug 1124944 - [Messages] Messages app opens as a blank screen when opened as a share activity multiple times

Unlock Console API for Gaia: bug 1066581

  • Status: The original bug is fixed by DevTools team, it's unclear whether or not we can/should turn on logs by default now.
  • Implication to v3: Issue is valid unless we never try to pass MTBF again.
  • 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 become 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.

P2

Nested oop apps: bug 1020135

  • Status: ?
  • Implication to v3: Issue is valid unless we don't have a centralized Settings app.
  • What this bug solves: Gaia apps like Settings app hosts many of the settings for other apps. It would be more technically sound if the Settings app could embed the said app instead, for the sake of code clarity and security model etc (bug ?). We would also need this to stop using activity to launch & go back from the keyboard settings panel (bug ?). It would unlock the 3rd-party app setting embedding as well (bug 1020063).

mozApps.getAll needs a filter based on "role" and "type": bug 1094562

  • Status: NOT STARTED
  • Implication to v3: Issue is valid unless we don't have a centralized Settings app.
  • What is being blocked: Performance issues involving mozApp.getAll() calls during start-up.
  • What this will solve: In settings app there are cases in which we have to find specific role or type of apps like homescreens, themes, or addons. Currently the only way would be getting all apps and check their properties one by one, which leads to performance issues. Providing a filter solves the performance issue during start-up.

Date & time format API: bug 1118214

  • Status: NOT STARTED (The mozAPI work is not going since the origin project(tako) request is canceled)
  • Implication to v3: Issue is valid unless we don't want to improve app start-up time.
  • What is being blocked: Apps displaying date and time now rely on a shim from gaia. The shim introduces additional loading time, potential racing, and settings migration issues.
  • What this bug solves: It should provide robust API for gaia apps to query the current date/time format. Moreover, it can also provide functions that generate localized date and time strings based on the current language setting. The alternative approach is improving mozSettings performance bug 1122570 therefore all mozSettings call are improved.

Bind permission Dialog to Browser Frame bug 853711

  • Status: NOT STARTED
  • Implication to v3: Issue is valid unless we never need to show permission dialog
  • What is being blocked: Permission dialog is not bind to the iframe who requests for the permission hence the dialog will show or hide at the wrong timing. One another case is fullscreen request is not dispatched from the mozBrowser iframe who enters fullscreen mode.
  • What this bug solves:

Migrate mozSettings values in Gecko: bug 1112092

  • Status: NOT STARTED
  • Implication to v3: Issue is valid unless we never upgrade hardware.
  • 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.