Closed
Bug 1348326
Opened 7 years ago
Closed 7 years ago
BBC video/audio fails to load after focusing the video’s tab
Categories
(Core :: Audio/Video: Playback, defect, P1)
Core
Audio/Video: Playback
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
platform-rel | --- | + |
firefox52 | --- | unaffected |
firefox53 | --- | unaffected |
firefox54 | --- | affected |
firefox55 | --- | affected |
People
(Reporter: emilghitta, Assigned: alwu)
References
Details
(Whiteboard: [platform-rel-BBC][platform-rel-BBCNews])
Attachments
(1 file)
2.03 MB,
image/gif
|
Details |
[Affected versions]: Firefox 54.0a2 (Build Id:20170317004022) Firefox 55.0a1 (Build Id:20170316030211) [Affected platforms]: Windows 10 64bit Windows 7 64bit MacOs 10.12 Ubuntu 16.04 64bit [Steps to reproduce]: 1. Launch Firefox. 2. Access the http://www.bbc.com/news/world-europe-39301003 weblink. 3. Open a random video in a new tab. 4. Wait until the tab successfully loads. 5. Focus the opened tab. 6. Observe that the video fails to load. [Expected result]: After switching to the opened video tab, the video and the audio is properly outputted. [Actual result]: After switching to the opened video tab, the video displays as it is loading but fails to do so. [Regression range]: This seems to be a regression: Last good revision: 7b8d033f771784cdf6f1048a92b5fd00ed48c43c First bad revision: 7f8d8f0964ff22d92ffb88abfd96246addd8a6b6 Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7b8d033f771784cdf6f1048a92b5fd00ed48c43c&tochange=7f8d8f0964ff22d92ffb88abfd96246addd8a6b6 I may be wrong, but I believe that this bug may cause the actual result: https://bugzilla.mozilla.org/show_bug.cgi?id=1338137 [Additional information]: Please note that the video loads successfully if the tab is refreshed.
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(alwu)
Updated•7 years ago
|
status-firefox52:
--- → unaffected
status-firefox53:
--- → unaffected
Assignee | ||
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(alwu)
Resolution: --- → DUPLICATE
Updated•7 years ago
|
Blocks: delay-autoplay
Reporter | ||
Updated•7 years ago
|
Blocks: qe-blockpb
Reporter | ||
Comment 2•7 years ago
|
||
We have retested this issue on Firefox latest Nightly and here are the following results: Not Working -Video is not displayed after focusing the opened tab but the audio can be heard. (In order to reproduce this issue you need to open a video in a new tab an wait approximately 15 seconds before focusing the opened tab) Working- The Play Tab indicator is displayed We have retested this issue using the following platforms: Windows 10 64bit Ubuntu 16.04 32bit. Windows 7 64bit . Alastor, could you take a look at the not working part?
Flags: needinfo?(alwu)
Assignee | ||
Comment 3•7 years ago
|
||
I tried to reproduce this issue with closing the pref "media.block-autoplay-until-in-foreground", and I found the video still can't be playback. So it seems we have some other thing broken, but it's not related with blocking autoplay.
Flags: needinfo?(alwu)
Reporter | ||
Comment 4•7 years ago
|
||
I just switched the pref "media.block-autoplay-until-in-foreground" to false and the issue is not reproducible. Note that I have tested on: Windows 10 64bit Ubuntu 16.04 32bit. Windows 7 64bit . Alastor, are you testing on Mac? If so, then you might be hitting bug 1350932.
Flags: needinfo?(alwu)
Assignee | ||
Comment 5•7 years ago
|
||
Yes, I tested it on the OSX. I'll check it on other platforms later, keep NI.
Assignee | ||
Comment 6•7 years ago
|
||
I think it's another different issue, it's not the same as bug1348759. I tested it on OSX, Window7, Ubuntu 14.04/16.04, I can only reproduce it successfully on Windows. OSX * the bug 1350932 blocks the testing on OSX, we can't confirm whether the issue exists Windows 7 * can reproduce if we wait long period after block, otherwise, the issue won't happen Ubuntu 14.04/16.04 * can't reproduce the issue, video would be stopped when I focus the tab (it's also weird, but the callstack shows that the stop was called by website) --- Now I still don't understand very well why this issue happen and why I got different behaviors on different platform. Need to investigate it more.
Assignee: nobody → alwu
Status: RESOLVED → REOPENED
Flags: needinfo?(alwu)
Resolution: DUPLICATE → ---
Comment 7•7 years ago
|
||
could it be the same as bug 1350932?
Assignee | ||
Comment 8•7 years ago
|
||
After applying the patch in bug 1350932, now the bbc video can be playback successfully on OSX. But I still can't reproduce this issue, the video would be stopped when I focus on the tab after waiting 5~10 sec after showing the "play tab" icon. This is the same as what I see on Ubuntu. This might be Windows specific bug.
Assignee | ||
Comment 9•7 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #7) > could it be the same as bug 1350932? I don't know, but it seems different issue. Because it would only start playing audio, not video (showing the spining icon) on Windows. But I can try to apply the patch on bug 1350932 and to see whether the issue still exists.
Assignee | ||
Comment 10•7 years ago
|
||
It's weird, I can still reproduce this issue on Nightly downloaded from release channel. but can't reproduce on my own build which is also latest Nightly on Window7. On my own build, the video would be paused like what I see on Unbuntu and OSX.
Assignee | ||
Comment 11•7 years ago
|
||
Now I can reproduce this issue on Linux and Windows, but not on OSX. Still trying to figure out what's happened.
Assignee | ||
Comment 12•7 years ago
|
||
Now I still don't know what's the root cause, but found the possible one. When we block the autoplay media, the loading process is still working on, so the client would receive the "canplay" and "canplaythrough" after getting enough data. And I also found that Chrome and Safari doesn't start loading process when the autoplay media was blocked. (Chrome and Safari don't have this issue) Therefore, I guess BBC website receives those event and then do something caused that issue. --- Hi, JW, If I postpone to dispatch "canplay" and "canplaythrough" when the tab is blocked, and dispatch them after tab is resumed. Do you think is it a good idea? Thanks!
Flags: needinfo?(jwwang)
Updated•7 years ago
|
Priority: -- → P1
Comment 13•7 years ago
|
||
No, I don't like the idea because it is playback that is blocked instead of the load algorithm. So we might want to also block the load algorithm as Chrome does when the media is blocked.
Flags: needinfo?(jwwang)
Assignee | ||
Comment 14•7 years ago
|
||
I would like to keep loading before the tab is resumed, there are two reasons, (1) We don't want to show the 'play tab' icon for media without audio track Those kinds of media often be used as background image or as EMOJI (like GIF-Video) and it's weird to show the icon for them. So we need to load the metadata first to know whether the media has audio track or not. (2) Reduce the waiting time before watching video Since user might open multiple background tabs and want it to load the data on the background before watching them so that it can help user reduce the waiting time. --- Hi, JW, For me, I think the first reason is more important, since it's the our difference with Chrome and Safari. The second one is less important because they don't implement the second feature as well. Another possible solution I thought is that we only load the metadata for the blocked media, and resume the loading and playing after the tab is resumed. How do you think? Thanks!
Flags: needinfo?(jwwang)
Comment 15•7 years ago
|
||
No, it won't work as expected. You can still get a 'canplay' event after just loading metadata.
Flags: needinfo?(jwwang)
Assignee | ||
Comment 16•7 years ago
|
||
After offline discussed with JW, he think BBC website should modify their code, instead of changing our event dispatching strategy. Client site should wait for play's promise or onplay event to know whether the play() start successfully or not, and it's incorrect to check the play state in "oncanplay" or "oncanplaythrough". --- Hi, Blake, Could you help us to contact with BBC? and help them modify their code? Thanks!
Flags: needinfo?(bwu)
Comment 17•7 years ago
|
||
IIUC, checking oncanplay event to play doesn't violate the spec. So it is not incorrect to do so, right?
Flags: needinfo?(bwu) → needinfo?(jwwang)
Comment 18•7 years ago
|
||
No, it doesn't. However, it makes the wrong assumption about the 'canplay' event which doesn't guarantee play() will succeed. As Alastor said, it should check the promise returned by play() to know if playback is started successfully.
Flags: needinfo?(jwwang)
Comment 19•7 years ago
|
||
After checking with Alastor, it looks like once BBC receives oncanplay event they expect to get play event or promise resolution within some time and otherwise it may retry. Then it may enter some error state which prevents us from resuming it when that tab goes to the foreground. I am going to see if we could get some ideas from BBC.
Updated•7 years ago
|
platform-rel: --- → ?
Whiteboard: [platform-rel-BBC][platform-rel-BBCNews]
Comment 21•7 years ago
|
||
(In reply to Blake Wu [:bwu][:blakewu] from comment #20) > After checking with BBC, this is a BBC bug. Blake, are they working on a fix? Should we move this to Tech Evangelism?
platform-rel: ? → +
Flags: needinfo?(bwu)
Assignee | ||
Comment 22•7 years ago
|
||
It seems BBC had fixed this issue, now I can't reproduce this issue again. Please feel free to reopen this bug if you see this issue again.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Flags: needinfo?(bwu)
Resolution: --- → WORKSFORME
Comment 23•7 years ago
|
||
Thanks!
You need to log in
before you can comment on or make changes to this bug.
Description
•