1024405 - [Flame] Video element cannot be used when we go back to homescreen and back to app

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[John Hu [:johnhu][:johu][:醬糊小弟]]

Attachment: log.txt

I haven't dig into the source. This happens to Gallery app, Video app, and Browser app with Youtube website.

In gallery app, the following message can be found at console:

E/GeckoConsole( 7439): [JavaScript Error: "TypeError: Value being assigned to HTMLMediaElement.currentTime is not a finite floating-point value." {file: "app://gallery.gaiamobile.org/js/frame_scripts.js" line: 1376}]

STR:
1. open gallery, video, or browser
2. play a video
3. press home
4. open app again and play the video again.

Logcat can be found at attachment.

Comment 1

[John Hu [:johnhu][:johu][:醬糊小弟]]

Attachment: issue happened to gallery app

Comment 2

[John Hu [:johnhu][:johu][:醬糊小弟]]

Attachment: issue happened to video app

Comment 3

[John Hu [:johnhu][:johu][:醬糊小弟]]

Attachment: issue happened to browser app

Comment 4

[John Hu [:johnhu][:johu][:醬糊小弟]]

The version information:

Gaia      508c85713fdf35eb2b3c8e8340e1d2ee306e6aec
Gecko     https://hg.mozilla.org/mozilla-central/rev/4876594bacaa
BuildID   20140611160203
Version   33.0a1
ro.build.version.incremental=94
ro.build.date=Tue May 20 09:29:20 CST 2014

Comment 5

[Jason Smith [:jsmith]]

This sounds like a regression. Can we check 2.0 & 1.4?

Comment 6

[Sotaro Ikeda [:sotaro]]

It seems Bug 1024324  or Bug 1029094.

Comment 7

[Chris Kreinbring [:CKreinbring]]

This issue does not repro on Flame 2.0 or Flame 1.4

2.0 Flame
Build ID: 20140625000201
Gecko: https://hg.mozilla.org/releases/mozilla-aurora/rev/79712bd7b60d
Gaia: de77f794db22a45f9d575de2c6e266a30a50de3b
Platform Version: 32.0a2
Firmware Version: v1.2.2
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

1.4 Flame
Build ID: 20140625000201
Gecko: https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/cddf88f78632
Gaia: c9416de14acf9e94ab006619cd2418c768422fcb
Platform Version: 30.0
Firmware Version: v1.2.2
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Actual Result: When the user relaunches the app and taps the Play button, the video resumes.

Comment 8

[Joshua Mitchell (Inactive)]

Qa-Wanted:  Let's also check in the latest Master with the Latest base

Comment 9

[Chris Kreinbring [:CKreinbring]]

This issue partially reproduces on the latest Flame 2.1

Build ID: 20140627040205
Gecko: https://hg.mozilla.org/mozilla-central/rev/9290d7995f98
Gaia: b8f36518696f3191a56e4f33447ee9d6ec820da1
Platform Version: 33.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Actual result: User cannot resume the video that was playing on the Gallery and Browser app.  On the Video app, the video feed can be resumed once the app is relaunched.

Comment 10

[Joshua Mitchell (Inactive)]

Nomming for 2.1 blocker - issue is a regression with a significant user impact

Comment 11

[Jason Smith [:jsmith]]

(In reply to Sotaro Ikeda [:sotaro] from comment #6)
> It seems Bug 1024324  or Bug 1029094.

Are you saying that this bug is caused by one of those two bugs? Or are you saying something else?

Comment 12

[Sotaro Ikeda [:sotaro]]

(In reply to Jason Smith [:jsmith] from comment #11)
> (In reply to Sotaro Ikeda [:sotaro] from comment #6)
> > It seems Bug 1024324  or Bug 1029094.
> 
> Are you saying that this bug is caused by one of those two bugs? Or are you
> saying something else?

Yes. Both bugs are regressions of Bug 979104.

Comment 13

[Jason Smith [:jsmith]]

Chris - Can you take a look when you get the chance? This appears to be a regression from the work done in bug 979104.

Comment 14

[Chris Pearce [:cpearce (Not reading bugmail)]]

Of course. I can reproduce this on my Otoro. I believe the problem is that I was not discarding enqueued samples when we make decoders dormant.

Comment 15

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch

Flush the samples enqueued in the state machine when we make decoders dormant. We use the same code path that we use when shutting down decoders, to ensure that there's no samples left alive waiting to be delivered in the task queues too.

This patch fixes the issue for me on the Otoro.

Comment 16

[Chris Pearce [:cpearce (Not reading bugmail)]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b30fb4ddf36d

Comment 17

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/b30fb4ddf36d

Comment 19

[bhavana bajaj [:bajaj]]

Switching the 2.1?->2.1+, on these fixed bugs as these are regression.

Nothing to land here, its just flag-cleanup of 2.1? list. Please Ni me if there is confusion/disagreement.

Comment 20

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

This issue is verified fixed on today's Flame 2.1

When playing a video, then tapping the home button, then re-opening the app the video is played in, the user can play the video without any issues. This has been verified in Gallery, Video, and Browser apps.


Flame 2.1 KK (319mb) (Full Flash)

Device: Flame 2.1 KK (319mb) (Full Flash)
BuildID: 20141012001201
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 21

[Ethan Tseng [:ethan]]

(In reply to Derek Harris [:DerekH] from comment #20)
> This issue is verified fixed on today's Flame 2.1
> 
> When playing a video, then tapping the home button, then re-opening the app
> the video is played in, the user can play the video without any issues. This
> has been verified in Gallery, Video, and Browser apps.

Great to hear that. Thanks Derek!