If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[Sound] Vibrate option is not available during/after FTU.

RESOLVED FIXED

Status

Firefox OS
Gaia::System
--
critical
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Leo, Assigned: alive)

Tracking

({regression})

unspecified
ARM
Gonk (Firefox OS)
regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:leo+, b2g18 verified, b2g-v1.1hd fixed)

Details

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
1. Title : [Sound] Vibrate option is not available during/after FTU.
2. Precondition : Prepare the device to enter FTU on start.
3. Tester's Action : Turn on the device and try volume-down.
4. Detailed Symptom (ENG.) : Observe the vibrate option is not available.
5. Expected : The vibrate option should be available.
6.Reproducibility: Y
           1)Frequency Rate : 100%
7.
Mozilla build ID: 20130518070206
Gaia Revision : 9380ceb81b3eac45861b8d1be07ab7f748ed52a3
8.Personal email id:  hanj.kim25@gmail.com

This is caused by the Bug 866036 patch.

It could be the first try-out through FTU for a user. First impression is important, there is a vibrate option!
(Reporter)

Updated

4 years ago
Component: Gaia::Settings → Gaia::System
See Also: → bug 866036
(Reporter)

Comment 1

4 years ago
Findings from debugging:
'appopen' event is received with "evt.detail.origin=app://communications.gaiamobile.org/ftu/index.html"
and the 'home' event is never received when FTU is completed and homescreen is displayed.
Therefore, homescreenVisible boolean stays false. It seems this causes the vibrate option disappear. And when phone is rebooted, this doesn't happen. (I believe, 'home' event is received.)


I have suggested the following solution but it's not clean.

  window.addEventListener('appopen', function(evt) {
    if (FtuLauncher.isFtuRunning())
      return;

    homescreenVisible = false;
  });

Any other approach?
Do we really need this?
It's an edge case that the user needs to reply a call during FTU.

I am c.c.ing UX for this.
Flags: needinfo?(kyee)
(Reporter)

Comment 3

4 years ago
Created attachment 754370 [details]
screenshots

Comment 4

4 years ago
Should be fixed, but certainly doesn't need to block.
Flags: needinfo?(kyee)
:cyee,

I really don't want a workaround to add a blacklist of apps in sound manager,
and I think the list will be grow in the future, if somebody is asking: "hey, calculator apps needs to modify notification channel", "hey, we need to modify notification channel in one more app...".
(Reporter)

Comment 6

4 years ago
Just realized that this happens not only through FTU, but also on any app.

Try volume up/down buttons when you are on Clock, or Calculator app. The vibrate option is not there..

This must be fixed ASAP.
Flags: needinfo?(alive)
(In reply to Leo from comment #6)
> Just realized that this happens not only through FTU, but also on any app.
> 
> Try volume up/down buttons when you are on Clock, or Calculator app. The
> vibrate option is not there..
> 
> This must be fixed ASAP.

This is intentional by bug 866036....
Flags: needinfo?(alive)
(Reporter)

Updated

4 years ago
blocking-b2g: --- → leo?
Depends on: 866036
blocking-b2g: leo? → leo+
Keywords: regression

Comment 8

4 years ago
(In reply to Alive Kuo [:alive] from comment #7)

I understand that content channel volume is changed when there is a visible app. (bug 866036)

Apart from that, the Vibrate option must be available when the homescreen is on foreground after FTU, right? Do you still think the following is no good?
(If you think so, then should we make homescreen to fire 'home' event to make the homescreenVisible = true; ?)

  window.addEventListener('appopen', function(evt) {
    if (FtuLauncher.isFtuRunning())
      return;

    homescreenVisible = false;
  });
Flags: needinfo?(alive)
(In reply to hanj.kim25 from comment #8)
> (In reply to Alive Kuo [:alive] from comment #7)
> 
> I understand that content channel volume is changed when there is a visible
> app. (bug 866036)
> 
> Apart from that, the Vibrate option must be available when the homescreen is
> on foreground after FTU, right? 

Sure! This is definitely true.
If it isn't so in homescreen than it's a bug.

I wonder something regresses about detection of homescreen app window is active..

> Do you still think the following is no good?
> (If you think so, then should we make homescreen to fire 'home' event to
> make the homescreenVisible = true; ?)

Don't fire home event...it's already used by hardware button manager.
Flags: needinfo?(alive)
(In reply to Alive Kuo [:alive] from comment #9)
> (In reply to hanj.kim25 from comment #8)
> > (In reply to Alive Kuo [:alive] from comment #7)
> > 
> > I understand that content channel volume is changed when there is a visible
> > app. (bug 866036)
> > 
> > Apart from that, the Vibrate option must be available when the homescreen is
> > on foreground after FTU, right? 
> 
> Sure! This is definitely true.
> If it isn't so in homescreen than it's a bug.
> 

BTW, I cannot reproduce using latest v1-train.
After FTU finishes, I could change notification channel on homescreen.

Comment 11

4 years ago
Created attachment 762507 [details]
Repro video

(In reply to Alive Kuo [:alive] from comment #10)

I have tested with the following version, which has a very minor change from v1-train version now.

https://raw.github.com/alivedise/gaia/7ee010ac21d15fe6a7b72434bce99bf576006614/apps/system/js/sound_manager.js
(A patch from Bug 882053 that I am testing at this time).

Please refer to the video attachment and see 00:27.

00:05 - The vibrate option is not there during FTU. (OK)
00:27 - FTU exited and homescreen is on foreground now. And the vibrate option is still not there. (NOT OK)
00:33 - Run a random app, clock.
00:39 - Press Home and homescreen is on foreground now. And the vibrate option is there. (OK)

Would you try again?
Attachment #762507 - Flags: feedback?(alive)
Good, I could repro now with latest v1-train. Thanks leo.
And I even see when at the first page on FTU the active channel is notification but when I go to enable-data page it turns to normal channel....
Taken.
Assignee: nobody → alive
Feel really sad it another FTU regression about comment 12.
At first page in FTU => notification channel because: FTU starts up on lockscreen
At second page in FTU => content channel because: FTU internally set lockscreen.enabled = false.
Depends on: 831697
Created attachment 762537 [details]
https://github.com/mozilla-b2g/gaia/pull/10381

Patch v1:
* Use ftudone event to track ftu is closed.
* Default channel during ftu running is notification.
Attachment #762537 - Flags: review?(timdream)
Comment on attachment 762537 [details]
https://github.com/mozilla-b2g/gaia/pull/10381

Sigh.
Attachment #762537 - Flags: review?(timdream) → review+
Attachment #762507 - Flags: feedback?(alive) → feedback+
v1-train
https://github.com/mozilla-b2g/gaia/commit/0b0cd9ee3eb9fb09f8505214615492bcc5eff7da

master
https://github.com/mozilla-b2g/gaia/commit/22718ae261800e8bc2230434e14012bdc2ffc602
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-b2g18: --- → fixed
Resolution: --- → FIXED
1.1hd: 0b0cd9ee3eb9fb09f8505214615492bcc5eff7da
status-b2g-v1.1hd: --- → fixed

Comment 19

4 years ago
Issue no langer reproduces on the Leo
 Build ID: 20130717070237
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/582e3a7018
Gaia: c506c50adaaebcf729ac3c27887ba2931ab79040
Platform Version: 18.1
Vibrate option is available during/after FTU
status-b2g18: fixed → verified
You need to log in before you can comment on or make changes to this bug.