Closed Bug 1188871 Opened 4 years ago Closed 4 years ago

Loading a page with media content on hangs indefinitely


(Firefox for Android :: Audio/Video, defect)

42 Branch
Not set



Firefox 43
Tracking Status
firefox39 --- unaffected
firefox40 --- unaffected
firefox41 --- unaffected
firefox42 --- fixed
firefox43 --- verified


(Reporter: JanH, Assigned: jya)





(2 files)

If I try loading a page with media content on, e.g., page loading hangs indefinitely, i.e. the progress bar progresses to approximately 80 %, but then never goes further.

In case it's a device specific bug, I'm using a Samsung Galaxy S3 Mini with the default Android 4.1.2.

Regression window is this one:
Flags: needinfo?(jyavenard)
Snorp, can you reproduce it ? any chance in providing a useful backtrace?
Flags: needinfo?(snorp)
Jan, are you able to compile Firefox yourself?
Flags: needinfo?(jh+bugzilla)
Unfortunately not, I'm on Windows.
Flags: needinfo?(jh+bugzilla)
I can reproduce this. Backtrace isn't very useful -- every thread is just waiting. Seems like maybe some state management has gone south?
do you still have the issue with today's Nightly?

I would have thought it was all related to bug 1188870
Flags: needinfo?(jyavenard) → needinfo?(jh+bugzilla)
No, they're only related insofar as I've encountered both bugs on the same page, and of course the crashes from bug 1188870 would have masked any further issues.
Now that those have been fixed, I'm seeing the hanging page loads again.
Flags: needinfo?(jh+bugzilla)
Assignee: nobody → jyavenard
I can't make sense of the regression window you've provided. There's nothing there that could prevent a page loading as it's not using MSE.

The only change related to media playback is the draining part which has been reverted in this try run:

is that something you could try?
Unfortunately, page load is still hanging on that try build.
I've also double-checked the regression range, but with the same result as before.
I have received my android device today, will be able to test myself.

What steps are you taking to come up with this regression range?
I run mozregression with this arguments:
> mozregression --app fennec --good=2015-07-16 --bad=2015-07-17

Then, once the Nightly has started up, I simply load
If page loading completes, i.e. the progress bar runs to completion and then disappears, I declare the build "good". If on the other hand, after a minute or so, page loading is still stuck at around 80 %, I declare the build "bad".

With the above regression range, the first inbound build mozregression tries should be "good", while the next one for me is already "bad".

Can reproduce the issue on a Sony Xperia z3c, with Android 5.1 ; so it's not just your device.

Will work on this tomorrow.
I woke up with an idea, and I'm fairly certain that's what the problem is.

In bug 1173657, I changed so should any discontinuity occurs (that includes an error) we then drain the decoder and wait for the DrainComplete message to get back.

Looking at the Android Decoder, when an error occurs, it exists its decode event loop.
The decode event loop is what handles the DrainComplete() message so it will never be fired and the reader will be waiting forever.
Part 1 prevented draining when an error occurred. This handles the case where an error occurs during draining.
Attachment #8647248 - Flags: review?(snorp)
Attachment #8647250 - Attachment description: Bug 1188871: P1. Don't drain decoders when an error is encountered. → P1. Don't drain decoders when an error is encountered.
Attachment #8647250 - Flags: review?(cpearce) → review+
Comment on attachment 8647248 [details] [diff] [review]
P2. Call DrainComplete should a decoder occurs while draining.

Review of attachment 8647248 [details] [diff] [review]:

Another good catch, thanks!
Attachment #8647248 - Flags: review?(snorp) → review+
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 43
Verified as fixed on Nightly (20150815030208).
Blocks: 1197083
Backed out for a youtube playback regression. See Bug 1199573.
Resolution: FIXED → ---
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.