1186572 - [FTU] Skipping through initial screen of tutorial will cause tutorial animated images to stop loading

Status: RESOLVED DUPLICATE of bug 1192748

(Core :: Audio/Video, defect)

Description

[Oliver Nelson [:oliverthor]]

Attachment: logcat_20150722_1229.txt

Description:
If the user is performing the FTU on a newly reset/flashed device, they will observe an animated tutorial of slides present at the end of setting up device information. If the user skips past the initial screen of the animated screens before it has time to load, they will break the loading of all the animated images they could display in the FTU.

Repro Steps:
1) Update a Aries to 20150722124026
2) Progress through FTU through to screen before tutorial.
3) Hit 'Next' to enter tutorial and quickly skip the first page before animated image loads.
4) Advance to next page and return to previous through tutorial observing images

Actual:
Images don't load after skipping the first image

Expected:
Images load on subsequent pages if a load is skipped


Environmental Variables:
-----------------------------

Device: Aries 2.5
Build ID: 20150722124026
Gaia: b57aef5b7f52c40f88ee4c069ff722404e8e8521
Gecko: 954706e7611c
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Device: Flame 2.5
BuildID: 20150722010204
Gaia: 84c3bf622e211046d905803b34de5d331761f22d
Gecko: 8e5c888d0d89
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
***************************

Issue DOES NOT REPRODUCE on 2.2 for flame devices
Results: Images load on subsequent pages if a load is skipped

Device: Flame 2.2
BuildID: 20150721162504
Gaia: e1e6317f17a840b19af9dbb25f5a771d8d9fa161
Gecko: a73051740290
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
-----------------------------


Repro frequency: 5/5
See attached: 
video- https://youtu.be/dYE2zFrHFKQ
logcat

Comment 1

[Sam Foster [:sfoster] (he/him)]

I wonder if this is fallout from bug 1017314, or bug 548523 (the platform bug that necessitated it), could we get window for this one - as you point out, this definitely used to work.

Comment 2

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Visible regression of FTU tutorials.

Comment 3

[Pi Wei Cheng [:piwei] (inactive)]

mozilla-inbound regression window:

Last Working
Device: Flame
BuildID: 20150710163851
Gaia: e4b63559eba364892867eb381c3002d6518e5d6a
Gecko: 07bcf36f5ab2
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5 Master) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

First Broken
Device: Flame
BuildID: 20150710170452
Gaia: e4b63559eba364892867eb381c3002d6518e5d6a
Gecko: 675ea719b91c
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5 Master) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=07bcf36f5ab2&tochange=675ea719b91c

Caused by changes made in Bug 1113086.

Comment 4

[KTucker [:KTucker][Inactive 3/4/2016]]

Andrea, can you take a look at this please? This looks to have been caused by the landing for bug 1113086.

Comment 5

[Andrea Marchesini [:baku]]

It seems a system app issue.

Comment 6

[Alastor Wu [:alwu]]

Hi, Oliver,
I can't reproduce this issue in Flame with latest version Gecko/Gaia. 
Besides, in recent period (after landing Bug1113086), I have seen the FTU lots of times, and I have not seen this situation.
Could you check it again? 
Thanks!

---

Here is my testing environment.
Gaia-Rev        aa1698251e86c820c50c045b0a3ff65fd6b0eee7
Gecko-Rev       254151:2ddec2dedced
Build-ID        20150723151847
Version         42.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.alastor.20150318.121016
FW-Date         三  3月 18 12:10:32 CST 2015
Bootloader      L1TC00011880

Comment 7

[Pi Wei Cheng [:piwei] (inactive)]

QA-Wanted to address the NI

Comment 8

[Pi Wei Cheng [:piwei] (inactive)]

This issue is still reproducing on latest nightly. The trick in reproducing this issue is to double-tap or triple-tap on the "Start Tour" button. Or you can look at the provided video carefully showing how to reproduce it.

https://www.youtube.com/watch?v=dYE2zFrHFKQ

Device: Flame (KK, 319MB, full flashed)
BuildID: 20150724010206
Gaia: ec2199b324304d3678b6a98a08a31bdc13c9e984
Gecko: cb8bdb8ffaef
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5 Master) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Comment 9

[Bobby Chien]

this can be reproduced as steps in comment 8. Once reproduced, FTU could not play video during introduction. 

Alastor, please help to track this per regression windows in comment 3.

----

Build ID               20150730150205
Gaia Revision          7e7e92fbeea90cad8bf6f494b1a73712f79178e8
Gaia Date              2015-07-30 17:03:31
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/23e525e2ba35
Gecko Version          42.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150712.193621
Firmware Date          Sun Jul 12 19:36:34 EDT 2015
Bootloader             L1TC000118D0

Comment 10

[Alastor Wu [:alwu]]

Attachment: Log : can't play video

Preliminary analysis, it seems that the system app turn off the tutorial video.
I'll continue to debug for more details.

Comment 11

[Alastor Wu [:alwu]]

Hi, Evan,
Could you help me check this issue?
From the log, it seem that the system app would mute the tutorial video.
Thanks!

Comment 12

[Evan Tseng [:evanxd]]

Hi Alastor,

It is a gecko bug.

If you follow the STR in comment 8(double-tap or triple-tap), the `audiochannelstatechanged` event from gecko is just triggered twice. For the first time, the state is active. And the second time is inactive.

You can see the below log with adding the gaia patch[1] and following the STR.
```
I/GeckoConsole( 7251): Content JS LOG: bug-1186572:audiochannelstatechanged: AppWindow_6_normal: true 
I/GeckoConsole( 7251): Content JS LOG: bug-1186572:audiochannelstatechanged: AppWindow_6_normal: false
```
As you see, the audio channel service will do `setMuted(false)` and `setMuted(true)`. Then you will get the result in comment 10.

[1]: https://github.com/evanxd/gaia/commit/5125fd8403c4c6b1ab7cc999523aa9e7c7eb0426

Comment 13

[Alastor Wu [:alwu]]

Attachment: Reset mMuted when we abort the exist load

The root cause is that we forgot to reset the mMuted when we want to abort the exist load. 

In FTU, every time we press the button ("Start/next/prev"), the FTU would reload the video. If we press the button more than once, that the old video would be discard and then reload the new one. 

In this step, the FTU use the same MediaElement, but replace the src link. Therefore, if we don't reset the mMuted in HTMLMediaElement::AbortExistingLoads(), we would get the wrong status of the media element even if we start the new load.

---

Try-server result.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4aea9d1677ef

Comment 14

[Sam Foster [:sfoster] (he/him)]

(In reply to Alastor Wu [:alwu] from comment #13)
> In FTU, every time we press the button ("Start/next/prev"), the FTU would
> reload the video. If we press the button more than once, that the old video
> would be discard and then reload the new one. 
> 
> In this step, the FTU use the same MediaElement, but replace the src link.
> Therefore, if we don't reset the mMuted in
> HTMLMediaElement::AbortExistingLoads(), we would get the wrong status of the
> media element even if we start the new load.

This is great news to get to the bottom of this. We've had occassional, hard to pin down problems like this since the tutorial videos landed, I'm optimistic this might have been the root cause. Is there anything I should change in the FTU to safeguard against these issues and to represent best practice for loading and displaying a series of videos like this?

Comment 15

[Alastor Wu [:alwu]]

Hi, Sam,
Do you think could we only load tutorial video once even if the user press the next button multiple times?
If the FTU could change this behavior and with my patch landing, I think that would be a good thing :)

Comment 16

[Alastor Wu [:alwu]]

Comment on attachment 8644850 [details] [diff] [review]
Reset mMuted when we abort the exist load

Hi, Robert,
Sorry to bother you,
Could you help me review this patch?

The root cause is that we forgot to reset the mMuted when we abort the exist load, that would cause the resource being suspended. (after the decoder setup, the NotifyOwnerDocumentActivityChangedInternal() would check the mMute to decide whether need to be suspended)

Because of that, we can't load the new src successfully, and the element can't have the enough data. Furthermore, the FTU only play the video after it finish loading, that is why we can't play the tutorial video.

Very appreciate :)

Comment 17

[Sam Foster [:sfoster] (he/him)]

(In reply to Alastor Wu [:alwu] from comment #15)
> Hi, Sam,
> Do you think could we only load tutorial video once even if the user press
> the next button multiple times?
> If the FTU could change this behavior and with my patch landing, I think
> that would be a good thing :)

I filed bug 1192978. Looking at the code in the FTU app, it looks like bad things could happen if users tap rapidly on the start/next buttons.

Comment 18

[Alastor Wu [:alwu]]

Thanks, Sam :)

Comment 19

[Alastor Wu [:alwu]]

Comment on attachment 8644850 [details] [diff] [review]
Reset mMuted when we abort the exist load

Cancel review, this method would result in other issue.

Comment 20

[Alastor Wu [:alwu]]

The patch of the bug1192748 would solve this issue, and it is a better solution.