Starting yesterday we began seeing reports of comments on YouTube no longer displaying via the Nightly Testers mailing list. Based on what I've seen this is being reported by people on multiple platforms (not just Windows) and back to at least Firefox 21 so far. I had these people try the usual things (safe mode, new profile, hardware acceleration off) and that didn't correct it. I also did some research and came across this thread: http://productforums.google.com/forum/#!searchin/youtube/comment/youtube/RQZgFU1RcjQ/Se71kcFzTVoJ The timing of this is somewhat indicative of something YouTube did on their end. Filing in Tech Evang as we have not been able to identify this as a Firefox regression in any particular version as of yet. I'll continue to work on trying to narrow this down to a Firefox version but I think it would be useful to conduct outreach to YouTube in parallel.

Matt, are we seeing comments related to this in SUMO or Input? Lukas, can you start working on the outreach to YouTube? It's trivial for me to reproduce this on Fedora 19 with Firefox 22 so I'll see if I can narrow this down to a previous Firefox version.

Steps to Reproduce: 1. Load http://www.youtube.com/watch?v=y364b2Hcq7I (or another video) 2. Find a comment with a reply 3. Click "Show the Comment" 4. Scroll down and move your mouse over that comment > Comment displays a lot of whitespace

I'm able to reproduce this easily in Firefox 19 and later, have not been able to reproduce this in Firefox 18 or earlier. While this could technically be our regression I would have expected to hear about this earlier or to have seen it in our Beta testing. I think now this is either something Youtube pushed recently that's exposing a regression or something YouTube is doing incorrectly based on an intended change in our code.

Bad: 2012-09-01(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #4) > I'm able to reproduce this easily in Firefox 19 and later, have not been > able to reproduce this in Firefox 18 or earlier. Scratch that, I've gone back and reproduced this to Firefox 17.0a1 2012-08-01 so far.

Reproduced back to Firefox 16.0a1 2012-07-01. I can't seem to get any earlier builds working on my system (startup crash) so this is as far back as I can go.

I've reached out to the moz/google discussion group to try and get eyes on it.

(In reply to lsblakk@mozilla.com [:lsblakk] from comment #7) > I've reached out to the moz/google discussion group to try and get eyes on > it. Thanks Lukas, did we want to track this?

Looks like the same issue as in bug 884468. While that's been open for about a month, it seems likely that some recent tweak on YouTube's end has made the problem even more apparent to users.

We are seeing some chatter on SUMO: https://support.mozilla.org/en-US/questions/965905 Not much on Input yet. It looks like un-maximizing the screen will get the comments to appear or just changing the screen size if you are not currently maximized. Volume is pretty low right now, but could increase. I'm looping in Verdi in case we need to get some content create for the workaround.

Since it's already a known issue and not something we can do anything about on our side (YouTube has already been notified via our google/mozilla list) there's not much to track here. It's aggravated recently and their site support should get them a sense of how many people their recent changes have affected.

I've been pointed to bug 157681 as the potential regressing bug here, Ehsan can you confirm? Again, since this has been in product for a while we wouldn't track but would consider a low risk uplift for fix.

(In reply to lsblakk@mozilla.com [:lsblakk] from comment #12) > I've been pointed to bug 157681 as the potential regressing bug here, Ehsan > can you confirm? Again, since this has been in product for a while we > wouldn't track but would consider a low risk uplift for fix. Could be. Somebody needs to bisect this and find a regression range.

Ioana, please have someone on your team find a regression range based on comment 13.

This Regression window From email with a helpful person: Last good nightly: 2012-06-06 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/06/2012-06-06-03-05-28-mozilla-central/ First bad nightly: 2012-06-07 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/06/2012-06-07-02-57-55-mozilla-central/

Pushlog from the range in comment 15: > https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6338a8988917&tochange=7e4c2abb9fc9 Unfortunately that change set is kind of broad and we don't have tinderbox builds going back this far. The only thing that possibly stands out to me is bug 755070 but that can't be can it? It's a change which should only affect Android.

I could reproduce this issue easily on: Mozilla/5.0 (X11; Linux i686; rv:21.0) Gecko/20100101 Firefox/21.0 Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20100101 Firefox/23.0 But never on (at least 15 tries): Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0 This makes me wonder how reliable the regression range could be (not referring just to the one in comment 15, but to any other range one could find). Another thing here: as a user I performed the scenario for this bug several times in the last releases and I didn't experience this bug once, so it might indeed be triggered/revealed by a youtube change.

This is a bug in Firefox, is regression from bug 157681. See a simple test case in bug 884468 comment 10. Steps to reproduce: 1. Go to https://bugzilla.mozilla.org/attachment.cgi?id=780675 2. Hover mouse over first line. 3. Press on CTRL and (+). 4. Hover mouse over second line. Actual results: Line disappear. Screenshot: http://img35.imageshack.us/img35/2426/odq.png Expected result: The first line should not disappear.

Although youtube's commentaries are working properly Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:25.0) Gecko/20130802 Firefox/25.0 ID:20130802030204 CSet: 76a944fa6b25 The steps provided by @blinky are still an issue.

(In reply to MarianG from comment #19) > The steps provided by @blinky are still an issue. I think we should wait for bug 884468 to be fixed then retest. If this case is still broken then a new bug should be reported. But, as I said, let's wait for bug 884468 to be resolved.

I'm going to close this bug for now. The original issue seems to be resolved and the bug it depends on hasn't been updated in 6 months. Please reopen if you find the issue still exists.