Last Comment Bug 1135078 - YouTube video playback start is very slow compared to Chrome with ipv6
: YouTube video playback start is very slow compared to Chrome with ipv6
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: unspecified
: x86_64 Windows 8.1
P1 normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Maire Reavy [:mreavy] Please needinfo me
Mentors:
: 1131426 1140085 (view as bug list)
Depends on:
Blocks: MSE youtube-mse
  Show dependency treegraph
 
Reported: 2015-02-20 07:56 PST by Sotaro Ikeda [:sotaro]
Modified: 2015-11-04 00:05 PST (History)
17 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
affected
affected
affected
unaffected


Attachments
ie's netowork log when starting youtube video playback with MES (28.75 KB, text/csv)
2015-03-06 08:42 PST, Sotaro Ikeda [:sotaro]
no flags Details
Wireshark log - youtube video playback via ie (7.43 MB, application/octet-stream)
2015-03-10 10:59 PDT, Sotaro Ikeda [:sotaro]
no flags Details
Wireshark log - youtube video playback via firefox (967.51 KB, application/octet-stream)
2015-03-10 10:59 PDT, Sotaro Ikeda [:sotaro]
no flags Details
out.cap (3.95 KB, application/octet-stream)
2015-03-11 14:30 PDT, Jeff Muizelaar [:jrmuizel]
no flags Details

Description User image Sotaro Ikeda [:sotaro] 2015-02-20 07:56:01 PST
When MSE is enabled for youtube video playback. It takes a long time(more than one minute) until youtube video playback start. Toronto office's WLAN connection is not good. Therefore I always face this problem. I strongly feel it during debugging bug 1128357.

STR
[1] Start Firefox nightly
[2] Start youtube video playback like the following.
     https://www.youtube.com/watch?v=09R8_2nJtjg


On the same machine and same network, Chrome browser's youtube video playback start quickly.

- Firefox nightly browser's youtube playback Mime Type: video/mp4; codecs="avc1.4d401e"

- chrome browser's youtube playback Mime Type: video/webm; codecs="vp9"
Comment 1 User image Sotaro Ikeda [:sotaro] 2015-02-24 13:12:36 PST
Anthony, is there a similar bug already?
Comment 2 User image Anthony Jones (:kentuckyfriedtakahe, :k17e) 2015-02-25 16:57:31 PST
Chrome reads different files - webm/vp9. Can you compare with IE?
Comment 3 User image Sotaro Ikeda [:sotaro] 2015-02-26 07:40:59 PST
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #2)
> Chrome reads different files - webm/vp9. Can you compare with IE?

IE takes longer time(around 10 sec) until starting youtube videos than chrome(around 3sec). But it is shorter than Firefox youtube with MES.

IE used same mime.as firefox.
type video/mp4; codecs="avc1.4d401e"
Comment 4 User image Sotaro Ikeda [:sotaro] 2015-02-26 07:44:42 PST
In Firefox, there were a case that it took very very long time and short time until start playback.
Comment 5 User image Sotaro Ikeda [:sotaro] 2015-02-26 07:47:06 PST
(In reply to Sotaro Ikeda [:sotaro] from comment #4)
> In Firefox, there were a case that it took very very long time and short
> time until start playback.

Once, the playback start became quick, other video's playbacks also seemed to become quick until the firefox shutdown.
Comment 6 User image Anthony Jones (:kentuckyfriedtakahe, :k17e) 2015-03-02 07:16:07 PST
Possibly related to bug 1137511.
Comment 7 User image Anthony Jones (:kentuckyfriedtakahe, :k17e) 2015-03-02 13:35:05 PST
How does it compare to Flash?
Comment 8 User image Sotaro Ikeda [:sotaro] 2015-03-02 14:19:17 PST
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #7)
> How does it compare to Flash?

On Flash, the PC failed to start video playback in majority cases. Just show "An error occurred, please try again later".
Comment 9 User image Jet Villegas (:jet) 2015-03-03 20:58:32 PST
Sanity-check: how does it behave when FF uses the Chrome UA string? It would be good to know if we're getting the same code/files as Chrome. It would also be good to know if Chrome is pre-fetching* here (test using a sniffing proxy like Charles.)

* https://developers.google.com/chrome/whitepapers/prerender?csw=1
Comment 10 User image Sotaro Ikeda [:sotaro] 2015-03-04 11:23:52 PST
It seems like dup of Bug 1131426.
Comment 11 User image Sotaro Ikeda [:sotaro] 2015-03-04 11:25:08 PST
(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> It seems like dup of Bug 1131426.

Network condition might just increase the delay.
Comment 12 User image Sotaro Ikeda [:sotaro] 2015-03-04 11:26:18 PST
Anthony, do we set this bug as invalid because of comment 10?
Comment 13 User image Sotaro Ikeda [:sotaro] 2015-03-04 11:30:29 PST
(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> It seems like dup of Bug 1131426.

I confirmed CORS error in console log.
Comment 14 User image Anthony Jones (:kentuckyfriedtakahe, :k17e) 2015-03-04 20:05:59 PST
I'm following up with YouTube. We'll leave it open for now just to track it.
Comment 15 User image Jet Villegas (:jet) 2015-03-05 12:40:36 PST
Sotaro: if you have a reliable repro case for this, please try setting security.turn_off_all_security_so_that_viruses_can_take_over_this_computer == true to see if CORS issues are actually to blame here. 

Of course, do not leave that flag set outside of this test :)
Comment 16 User image Sotaro Ikeda [:sotaro] 2015-03-06 08:27:16 PST
(In reply to Jet Villegas (:jet) from comment #15)
> Sotaro: if you have a reliable repro case for this, please try setting
> security.turn_off_all_security_so_that_viruses_can_take_over_this_computer
> == true to see if CORS issues are actually to blame here. 

I tried the pref, but it seems not work to disable CORS. The CORS error messages were still exist. From Bug 1039678, we might not have a way to disable CORS by pref/setting.
Comment 17 User image Sotaro Ikeda [:sotaro] 2015-03-06 08:42:05 PST
Created attachment 8574007 [details]
ie's netowork log when starting youtube video playback with MES

When youtube video playback is started with IE, I always saw that fist XHR for audio data and first XHR for video data were failed, another XHRs seemed to receive actual data.
Comment 18 User image Sotaro Ikeda [:sotaro] 2015-03-06 08:53:56 PST
I am not sure how to disable CORS locally. From the source, modifying nsCORSListenerProxy::CheckRequestApproved() seems do it. By modifying CheckRequestApproved(), I did not see the CORS error logs.

https://dxr.mozilla.org/mozilla-central/source/dom/security/nsCORSListenerProxy.cpp#528
Comment 19 User image Sotaro Ikeda [:sotaro] 2015-03-06 09:09:21 PST
When I tried to playback same video several times, youtube video playback seems to becomes very quick. In this case, I did not see the CORS error nor XHR without data receive.
Comment 20 User image Sotaro Ikeda [:sotaro] 2015-03-06 09:15:16 PST
(In reply to Sotaro Ikeda [:sotaro] from comment #17)
> Created attachment 8574007 [details]
> ie's netowork log when starting youtube video playback with MES
> 
> When youtube video playback is started with IE, I always saw that fist XHR
> for audio data and first XHR for video data were failed, another XHRs seemed
> to receive actual data.

On Firefox, first 7 XHRs for audio and 7 XHRs for video seems aborted when the problem happens.
Comment 21 User image Sotaro Ikeda [:sotaro] 2015-03-06 09:26:11 PST
(In reply to Sotaro Ikeda [:sotaro] from comment #20)
> (In reply to Sotaro Ikeda [:sotaro] from comment #17)
> > Created attachment 8574007 [details]
> > ie's netowork log when starting youtube video playback with MES
> > 
> > When youtube video playback is started with IE, I always saw that fist XHR
> > for audio data and first XHR for video data were failed, another XHRs seemed
> > to receive actual data.
> 
> On Firefox, first 7 XHRs for audio and 7 XHRs for video seems aborted when
> the problem happens.

The number of XHR abort seems different each time on firefox. first 3 XHRs for audio and 3 XHRs abort seems also common.
Comment 22 User image Sotaro Ikeda [:sotaro] 2015-03-06 09:27:55 PST
(In reply to Sotaro Ikeda [:sotaro] from comment #18)
> I am not sure how to disable CORS locally. From the source, modifying
> nsCORSListenerProxy::CheckRequestApproved() seems do it. By modifying
> CheckRequestApproved(), I did not see the CORS error logs.
> 
> https://dxr.mozilla.org/mozilla-central/source/dom/security/
> nsCORSListenerProxy.cpp#528

I am not sure the above check actually disable CORS, because even after changing the CheckRequestApproved(), the XHRs aborts happened same way.
Comment 23 User image Anthony Jones (:kentuckyfriedtakahe, :k17e) 2015-03-08 00:51:40 PST
(In reply to Sotaro Ikeda [:sotaro] from comment #22)
> I am not sure the above check actually disable CORS, because even after
> changing the CheckRequestApproved(), the XHRs aborts happened same way.

I'm told that the issue is that the CORS headers are only missing from other errors and not from real content. That doesn't seem to be the case for me. However I'm getting CORS errors a few times an hour. I only get this from the office Internet which has a funny idea of what country it is in and that is apparently part of the issue. How big a part, I don't know.

Do you experience this issue only at the office or can you reproduce the problem from your home?
Comment 24 User image Anthony Jones (:kentuckyfriedtakahe, :k17e) 2015-03-08 21:48:48 PDT
*** Bug 1131426 has been marked as a duplicate of this bug. ***
Comment 25 User image Anthony Jones (:kentuckyfriedtakahe, :k17e) 2015-03-09 17:18:32 PDT
Can you get some logs through wireshark for the different browsers?
Comment 26 User image Sotaro Ikeda [:sotaro] 2015-03-09 17:30:54 PDT
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #23)
> 
> Do you experience this issue only at the office or can you reproduce the
> problem from your home?

No, I experience it only from Toronto office.
Comment 27 User image Sotaro Ikeda [:sotaro] 2015-03-09 17:31:28 PDT
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #25)
> Can you get some logs through wireshark for the different browsers?

I will try it tomorrow.
Comment 28 User image Jeff Muizelaar [:jrmuizel] 2015-03-10 09:44:02 PDT
I had a look at this and it looks like it is caused by ipv6.

The following command hangs:

curl -6 'https://r1---sn-gxuxapu-hm2e.googlevideo.com/videoplayback?key=yt5&ip=2001%3A450%3A1f%3A224%3Aad0e%3Af3f2%3A1b90%3A1d3&mm=31&signature=B309F1278B3E598B2F34D2FB4745107DAB7292EE.8917C6D467EFFC7C4D90EEA2D7ECA3350F444FD0&mv=u&mt=1426001559&ms=au&id=o-AMK3FzCiH_aN6N2sMtJxPqys2HJ8i8P1pTGHOQXFfSQI&lmt=1417129991745982&source=youtube&sver=3&dur=124.853&itag=140&sparams=clen%2Cdur%2Cgir%2Cid%2Cip%2Cipbits%2Citag%2Clmt%2Cmm%2Cms%2Cmv%2Cpl%2Crequiressl%2Csource%2Cupn%2Cexpire&requiressl=yes&clen=1505649&ipbits=0&expire=1426023298&fexp=900225%2C904844%2C907263%2C913444%2C924630%2C927622%2C934952%2C934953%2C934954%2C936120%2C9405634%2C9406012%2C9406282%2C943917%2C948124%2C951703%2C952302%2C952612%2C952901%2C955301%2C957201%2C959701&gir=yes&upn=rTwIU7yHZXQ&pl=48&cpn=lEFD4CDK6iZ31ulW&alr=yes&keepalive=yes&ratebypass=yes&mime=audio%2Fmp4&c=web&cver=html5&range=0-65535' -H 'Host: r1---sn-gxuxapu-hm2e.googlevideo.com' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:39.0) Gecko/20100101 Firefox/39.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Referer: https://www.youtube.com/embed/ZuTQR6xSbNM?autoplay=1&wmode=transparent&origin=https://video.search.yahoo.com&html5=1' -H 'Origin: https://www.youtube.com' -H 'Connection: keep-alive'

If you take away the -6 it works fine.

We seem to eventually timeout and switch to ipv4. We should tell google to fix this.
Comment 29 User image Chris Peterson [:cpeterson] 2015-03-10 10:32:14 PDT
Sotaro, are you using IPv6?
Comment 30 User image Sotaro Ikeda [:sotaro] 2015-03-10 10:47:54 PDT
(In reply to Chris Peterson [:cpeterson] from comment #29)
> Sotaro, are you using IPv6?

Yes, I confirmed IPv6 usage for youtube site by using Wireshark.
Comment 31 User image Chris Peterson [:cpeterson] 2015-03-10 10:50:52 PDT
I am reaching out to our YouTube contacts now.
Comment 32 User image Sotaro Ikeda [:sotaro] 2015-03-10 10:59:10 PDT
Created attachment 8575423 [details]
Wireshark log - youtube video playback via ie
Comment 33 User image Sotaro Ikeda [:sotaro] 2015-03-10 10:59:53 PDT
Created attachment 8575425 [details]
Wireshark log - youtube video playback via firefox
Comment 34 User image Richard Leider 2015-03-11 10:45:40 PDT
Would it be possible to get a tcpdump from someone who can reproduce this problem?
Comment 35 User image Jeff Muizelaar [:jrmuizel] 2015-03-11 14:30:19 PDT
Created attachment 8576263 [details]
out.cap

I sent this to Richard by email. But here it is for anyone else who's interested. The server does not respond to any of our syn packets.
Comment 36 User image Richard Leider 2015-03-11 15:21:21 PDT
Thanks so much for the examples.  Jeff, could I ask you for an additional bit of info? Could you right click on the player, select Copy Debug Info and paste the result here for a Firefox IPv6 playback that demonstrates this issue?  

The tcpdump shows some potentially interesting behavior but doesn't show what the application level player code is doing.  The Debug Info can sometimes makes that easier to infer.
Comment 37 User image Justin L. 2015-03-11 22:24:03 PDT
I'm also having this problem, or one that seems to be the same. I created an account here just to help out. I'm not sure when it started, but it's recent, in the past few days. When I try to load any youtube video, I'm greeted with the buffer wheel for anywhere from 10-30 seconds. Then, either I'm met with the youtube error message or the video loads but on a low resolution, and the higher resolutions are greyed out and unable to select. Usually in this case I refresh the page once or twice, and then the video finally loads. In comparison, Chrome loads all these videos immediately with no wait.

Things I've tried:

Uninstall and reinstall firefox flash player
Disable/Delete all extensions
Uninstall Firefox, reinstall current version (36.0.1)
Complete clean uninstall (even removing the mozilla folder from appdata/roaming)

Nothing seems to work. Let me know if I can be of any help and send you any info.
Comment 38 User image Dragana Damjanovic [:dragana] 2015-03-12 01:33:22 PDT
Can make  http log:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Comment 39 User image Lawrence Mandel [:lmandel] (use needinfo) 2015-03-12 12:28:15 PDT
Tracking 37+ as this is important for MSE.
Comment 40 User image Jason Duell [:jduell] (needinfo me) 2015-03-12 15:09:03 PDT
Sotaro: can you follow comment 38 and get an HTTP log for this while it's happening?  

[Note that HTTP logs can possibly contain cookies, so if this is a real profile you use regularly, either look over the log to make sure there's no confidential info in it before you attach it here Or you can just email it directly to Dragana.]
Comment 41 User image Jeff Muizelaar [:jrmuizel] 2015-03-12 15:28:41 PDT
Here's the debug info from a session. It didn't seem to hang as long though and didn't seem to have the same ipv6 problem.

{"ns":"yt","el":"embedded","cpn":"8Wno7-FzUv16p46o","docid":"ZuTQR6xSbNM","ver":2,"referrer":null,"cmt":"6.42","plid":"AAURHt-cqHnD1Jyh","ei":"jRICVfS6LYbMqAOo1oKwBQ","fmt":"133","fs":"0","rt":"9.849","of":"T_k3IsmKkcxGOR81mofITw","adformat":null,"content_v":null,"euri":"","subscribed":null,"lact":1,"live":null,"cl":"88303760","mos":0,"osid":null,"state":null,"vm":null,"volume":59,"c":"web","cver":"html5","cplayer":"UNIPLAYER","cbr":"Firefox","cbrver":"39.0","cos":"Macintosh","cosver":"10.9","autoplay":"1","hl":"en_US","cr":"CA","len":"124","fexp":"900225,904844,907263,913444,924630,927622,934952,934953,934954,936120,9405634,9406012,9406938,9407103,9407793,943917,947243,948124,951511,951703,952302,952612,952901,955301,957201,959701","afmt":"140","vct":"6.420","vd":"124.000","vpl":"0.000-6.420,","vbu":"0.000-59.999,","vpa":false,"vsk":false,"vpr":1,"vrs":3,"vns":2,"vec":null,"lct":"6.177","lsk":false,"lmf":false,"lbw":"472686.320","lhd":"0.250","ltd":"16.234","laa":"itag=140,seg=5,range=603666-724055,time=50.0,60.0","lva":"itag=133,seg=13,range=1990181-2144478,time=65.0,70.0","lar":"itag=140,seg=5,range=603666-724055,time=50.0,60.0","lvr":"itag=133,seg=13,range=1990181-2144478,time=65.0,70.0","lvh":"r13---sn-p5qlsnlr","lab":"0.000-59.999,","lvb":"0.000-70.000,","debug_videoId":"ZuTQR6xSbNM","debug_playbackQuality":"small","debug_date":"Thu Mar 12 2015 18:26:32 GMT-0400 (EDT)"}
Comment 42 User image Jeff Muizelaar [:jrmuizel] 2015-03-12 15:30:19 PDT
I'm not getting the same CORS issue anymore right now either.
Comment 43 User image Jeff Muizelaar [:jrmuizel] 2015-03-12 15:31:22 PDT
I can however still reproduce the hangs when trying to connect to the original r1---sn-gxuxapu-hm2e.googlevideo.com host
Comment 44 User image Dragana Damjanovic [:dragana] 2015-03-13 00:41:47 PDT
Jeff, can you also send a http log when it hangs?
Comment 45 User image Sotaro Ikeda [:sotaro] 2015-03-13 07:48:35 PDT
(In reply to Jason Duell [:jduell] (needinfo? me) from comment #40)
> Sotaro: can you follow comment 38 and get an HTTP log for this while it's
> happening?  
> 
> [Note that HTTP logs can possibly contain cookies, so if this is a real
> profile you use regularly, either look over the log to make sure there's no
> confidential info in it before you attach it here Or you can just email it
> directly to Dragana.]

Today, I tried several times, but the hang did not happen.
Comment 46 User image Sotaro Ikeda [:sotaro] 2015-03-13 07:51:59 PDT
(In reply to Sotaro Ikeda [:sotaro] from comment #45)
> (In reply to Jason Duell [:jduell] (needinfo? me) from comment #40)
> > Sotaro: can you follow comment 38 and get an HTTP log for this while it's
> > happening?  
> > 
> > [Note that HTTP logs can possibly contain cookies, so if this is a real
> > profile you use regularly, either look over the log to make sure there's no
> > confidential info in it before you attach it here Or you can just email it
> > directly to Dragana.]
> 
> Today, I tried several times, but the hang did not happen.

It means youtube playback did not hang today.
Comment 47 User image Justin L. 2015-03-13 08:33:24 PDT
I made and HTTP log while youtube was lagging to help you out, but I cannot post it, because it is too long. I also cannot attach it because the file is too big. How do I post the log file? Can I email it to someone?
Comment 48 User image Dragana Damjanovic [:dragana] 2015-03-13 08:35:14 PDT
Justin, you can e-mail it to me.
Comment 49 User image Justin L. 2015-03-13 08:38:43 PDT
What's your email? Is it the dd.mozilla@gmail?
Comment 50 User image Dragana Damjanovic [:dragana] 2015-03-13 08:43:47 PDT
Yes, thank you.
Comment 51 User image Justin L. 2015-03-13 08:45:18 PDT
Okay, sending it now. I hope this will help you guys figure it out. I use youtube every day and having each video take several tries to load is very annoying. Let me know if I can help in any other way.
Comment 52 User image Dragana Damjanovic [:dragana] 2015-03-17 08:26:29 PDT
The problem is that happy-eyeballs is not working properly....

I made a patcha nd than figure out that there is another bug already salving this.

so it is dup of 1136484
Comment 53 User image Dragana Damjanovic [:dragana] 2015-03-17 08:27:06 PDT

*** This bug has been marked as a duplicate of bug 1136484 ***
Comment 54 User image Liz Henry (:lizzard) (needinfo? me) 2015-03-17 15:21:50 PDT
Untracking this since it's a duplicate; tracking 1136484 instead.
Comment 55 User image Dragana Damjanovic [:dragana] 2015-03-19 01:33:13 PDT

Nick (https://bugzilla.mozilla.org/show_bug.cgi?id=1136484#c28) is right there are two problems here 

The tcpdump from Jeff is a happy eyeballs problem and http log is a happy-eyeball problem as well.

but the tcpdump from Sotaro is different:
we start connection to r1.sn-nx57ynes.googlevideo.com (2607:f8b0:400a:a::6) (send tls handshake)
and than we abort connection, sending Encrypted Alert and a FIN.

so one part is duplicate of 1136484 and the other not.
Comment 56 User image Ralph Giles (:rillian) | needinfo me 2015-03-23 15:10:22 PDT
How serious do you think the remaining issue is? Should this still be a top-priority bug?
Comment 57 User image Dragana Damjanovic [:dragana] 2015-03-24 11:19:42 PDT
Justin's http log (comment #51) and Jeff's
Comment 58 User image Dragana Damjanovic [:dragana] 2015-03-24 11:45:24 PDT
Sorry accidentally posted the comment....

Sotaro could not reproduce the problem - comment #45, it seems that youtube fixed it.
The same problem is reported in bug 1131426.

But I will ask Patrick.. I am not sure who is the right person to ask. (note: some comment on the tcpdump is in comment #55)
Comment 59 User image Patrick McManus [:mcmanus] 2015-03-24 12:29:01 PDT
So, as I understand this there were 2 sources of problems:

1] is bug 1131426, which is recently fixed on 38 and 39 and wontfix 37

2] is a yt side CORS problem that seems to have been fixed around 3/12

looking at the logs that seems right.

one question I had about 1131426 was why it was linked to eme and that was never justified in the bug - that was part of why we wontfix'd it for 37 given the short timeline. however, I think I understand now - without eme the video is retrieved via flash using a separate stack that does not run into 1131426. Is it correct that eme is a 37 feature?

I can't assess how painful this is now that the cors issue is resolved. If someone can still repro on 37 and wants to try and quantify how big of an issue it is then that show be good feedback to lawrence on revisiting his decision to wontfix it on 37.

The yt test itself from tor is probably the best directed testing that could be done (on 38/39)
Comment 60 User image Chris Peterson [:cpeterson] 2015-03-24 23:38:44 PDT
(In reply to Patrick McManus [:mcmanus] from comment #59)
> one question I had about 1131426 was why it was linked to eme and that was
> never justified in the bug - that was part of why we wontfix'd it for 37
> given the short timeline. however, I think I understand now - without eme
> the video is retrieved via flash using a separate stack that does not run
> into 1131426. Is it correct that eme is a 37 feature?

Small correction: bug 1131426 was using MSE, not EME (DRM). We have asked YouTube to only serve HTML5 video to Firefox versions that support MSE.
Comment 61 User image Anthony Jones (:kentuckyfriedtakahe, :k17e) 2015-03-29 19:38:00 PDT
(In reply to Patrick McManus [:mcmanus] from comment #59)
> 2] is a yt side CORS problem that seems to have been fixed around 3/12

This is us generating a CORS error when YouTube calls abort() on a hung request.
Comment 62 User image Anthony Jones (:kentuckyfriedtakahe, :k17e) 2015-04-14 20:13:48 PDT
Dragana - is there an easy way to pref-off ipv6 to test/prove a user has an ipv6 problem?
Comment 63 User image Dragana Damjanovic [:dragana] 2015-04-14 21:55:30 PDT
there is a pref network.dns.disableIPv6 in about:config you can set it to true.
Comment 64 User image Dragana Damjanovic [:dragana] 2015-04-14 22:53:56 PDT
According o comment #59 both problems are fixed, so closing this bug.
Comment 65 User image Anthony Jones (:kentuckyfriedtakahe, :k17e) 2015-09-28 11:53:04 PDT
*** Bug 1140085 has been marked as a duplicate of this bug. ***
Comment 66 User image Aissen 2015-11-03 06:26:55 PST
Just got this CORS issue with a YouTube video loading a https://r1---sn-cg07luez.googlevideo.com/videoplayback?... video.
Comment 67 User image Chris Peterson [:cpeterson] 2015-11-03 09:32:42 PST
Aissen, that's very interesting. Are you using IPv6? Have you seen this CORS issue more than once? If you have can, you please share the YouTube page URL and your Firefox's about:support information?

Instructions:

https://support.mozilla.org/en-US/kb/use-troubleshooting-information-page-fix-firefox
Comment 68 User image Aissen 2015-11-03 23:49:29 PST
YouTube URL: https://www.youtube.com/watch?v=sHHoQX87xsg
AFAIK, I have no IPv6 enabled (can't ping6 gogole, have only an fe80:: link local adress on the interface)

I disabled my ad blocker, but the issue is still here.

I can't reproduce it after upgrading from firefox 41.0.2 to firefox 42.
Comment 69 User image Chris Peterson [:cpeterson] 2015-11-03 23:56:15 PST
If the video still played after you saw the CORS message, I think you might have seen bug 1152574, which was fixed in Firefox 42. The CORS message was incorrectly shown when a website was aborting XHR requests (such as when you skip ahead in a YouTube video).
Comment 70 User image Aissen 2015-11-04 00:05:42 PST
The video did not play at all, but as I said it now works in Firefox 42; you can ignore this report.

Note You need to log in before you can comment on or make changes to this bug.