[Tracking Requested - why for this release]: STR: 1. Go to https://www.youtube.com/new 2. Click the blue "go to youtube" button. Actual: In FF55 the outer frame of the page will appear, no content will be shown in the main area. In FF53 and FF54 content will be shown.
Note, trying to load the page with the network monitor seems to trigger the content load. It makes it hard to tell if its a network problem or something else. No errors in web console.
Disabling requestIdleCallback in FF 55 seems to make the site work. This could either be an incorrect use of requestIdleCallback in YouTube or something wonky with the FF55 implementation.
Andreas, there appears to be a compat issue with out requestIdleCallback on the new youtube site. Can you take a look?
2 years ago
Component: Untriaged → DOM
Tracking 55+ while we investigate this you tube issue.
status-firefox55: --- → affected
tracking-firefox55: ? → +
Assignee: nobody → afarre
2 years ago
I can't get this to reproduce on my locally built FF. Awaiting response on youtube mailing list.
status-firefox53: --- → unaffected
status-firefox54: --- → unaffected
I tried to reproduce as well, without any luck.
Got this back from Calvin and Ziling in private email (they said I could post here): > Quick update, I believe the issue is on YouTube's side and not with Firefox's > requestIdleCallback implementation. We uncovered a race condition in the app logic > that is causing an exception. And: > Its possible that its aggravated by requestIdleCallback being more aggressive in > mozilla vs. chrome though. Maybe exacerbated by the setTimeout event queue change. So I believe they have fixed the immediate problem on their end. I think the open question, though, is if there is a compat problem in the "more aggressive behavior". I'll ask them to elaborate.
FWIW I *just* reproduced it a couple of times. I reloaded twice and the second one loaded the full page. Do you know if the changes that were supposed to fix the bug on their side were rolled out to all users? Could it be that the bug hasn't been completely fixed yet?
Just a thought, we don't have timer aware idle request yet (bug 1311425). That might affect to the behavior quite a bit.
I don't know that they fixed it yet, just what I quoted above.
FTR I just reproduced once more. This time the problem only went away after the 5th reload. (Not sure how helpful these comments are. I'll stop commenting on the bug unless if someone tells me I'm helping somehow...)
Latest update from YouTube: "I caveat that this is specific to our application and bootstrap logic, but I did notice FF fires idle callbacks sooner than Chrome. Possibly more frequently, I didn't take any measurement of that. We'll have a fix out early next week, we'll update you." So it sounds like not fixed on their end yet.
Given that the "early next week" has passed and I am now able to reproduce on almost every request to the initial home page, maybe now would be a good time to follow up. Ben, since you started the thread on the mailing list, would you mind sending a quick ping?
Sorry, I got an email from them: "The fix for FF 55 will be delayed a bit. A workaround fix was in place but we've decided to revert it and tackle the core bug which will take some time. We're actively working on it. Thanks for your patience!" I keep getting confused about whats on the bug, ML, or private message.
Ah, okay! Thanks then! :) Just wanted to make sure we definitely get a fix before they decide to go live, because that's really annoying. I also am really interested in what the actual issue is... maybe there is something in Gecko we should fix instead of them placing workarounds? :/
(In reply to Dennis Schubert [:denschub] from comment #16) > I also am really interested in what the actual issue is... maybe there is > something in Gecko we should fix instead of them placing workarounds? :/ Based on the feedback I got from them they had race conditions in their code. Since our requestIdleCallback() implementation is different than chromes they got different timing and broke. So far they haven't pointed us to anything that shows our requestIdleCallback() is breaking the spec, though.
Moving to TE since this is something YT is working on.
Component: DOM → Desktop
Product: Core → Tech Evangelism
Andrew, any updates?
Whiteboard: [platform-rel-Youtube] → [platform-rel-Youtube][sitewait]
On our mailing list they said they're working on it (on May 31st).
Can anyone still reproduce this?
WFM now. Not sure what changed.
Dennis, can you still repro? If not, let's close it.
Seems to work now. Great. :)
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
This seems to have regressed today - is anyone able to confirm? (not ni?ing anyone specific, just hoping for people to say "no, it works fine for me!")
I'm asking the youtube folks on the mailing list...
Reopening, since the regression was confirmed by YouTube. People are working on it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
We haven't seen reports about this for a long time, let's close again. Thanks YouTube!
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago → 7 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.