1206912 - "sensitive material" video posted on twitter doesn't show up after I press "View Content"

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 0. Don't be logged in to Twitter. (e.g. open a private-browsing tab)

 1. Visit https://twitter.com/_youhadonejob/status/646071068403331072
  --> Note the "Sensitive material" disclaimer. Don't worry, there's nothing NSFW/disturbing in the video. (not sure why the disclaimer is there.

 2. Click "View content"

ACTUAL RESULTS:
A big blank area appears. DOM inspector shows that the blank area is this empty div:  <div class="player-wrapper"></div>

EXPECTED RESULTS:
Video should appear.


I get EXPECTED RESULTS in Chrome.
I also get EXPECTED RESULTS in Firefox, *if* if I'm logged into twitter so that I bypass the "sensitive content" disclaimer. (because my twitter account settings allow sensitive content.)

I can repro on Linux (using Firefox release, from Ubuntu with H.264 video support), as well as on Windows (using Firefox Nightly 2015-09-19)

So it seems something is breaking during the "View content" flow.  I'm filing this as a Tech Evangelism bug, since it doesn't seem to be a regression.  But it's possible this is actually a Firefox bug.  (I'm hoping a Twitter dev can take a look, and if they think it is a Firefox bug, hopefully they can tell us what's failing in their flow here.)

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)
> ACTUAL RESULTS:
> A big blank area appears. DOM inspector shows that the blank area is this
> empty div:  <div class="player-wrapper"></div>

Actually -- forget about that node -- it's empty in Chrome, too. It gets populated later on, when you actually start watching the video.

The video preview-image that's shown in Chrome is actually this node:
<div class="poster-image-container" style="display: block;">

That node (poster-image-container) has "display:none" in a stylesheet, but the inline display:block style (in Chrome) makes it visible.  But when I perform the STR in Firefox, this node doesn't receive this inline style.  If I manually apply it in devtools, then everything works as expected.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug, & of workaround in devtools

Comment 3

[Daniel Holbert [:dholbert]]

I reported the issue using twitter's form at
 https://support.twitter.com/forms/feature_report_submitted?regarding=videos_missing

Comment 4

[Daniel Holbert [:dholbert]]

I reported the issue using twitter's form at
 https://support.twitter.com/forms/feature_report?feature=videos

Comment 5

[Daniel Holbert [:dholbert]]

(I'm not sure whether the feedback-form that I submitted actually reaches any Twitter devs; seems like it might just end up in a huge dataset that they mine to discover frequently-reported issues.  So: if we have a contact for reporting Twitter bugs, it's probably worth reaching out to them as well.)

Comment 6

[Karl Dubost💡 :karlcow]

There was something similar on webcompat.com but I could not reproduce
https://webcompat.com/issues/1716

But this one seems slightly different and I can reproduce.

https://github.com/necolas helped us in the past.

Comment 7

[Hallvord R. M. Steen [:hallvors]]

I just tested in a nightly build and could not see any problems.

Comment 8

[Daniel Holbert [:dholbert]]

I can definitely reproduce on Nightly, using Windows & Linux. BUT, I noticed one crucial thing that seems to be required for this to reproduce:  *wait until the page has fully loaded* before you click "View content".

If I click the "View content" button while the page is loading, then I can't reproduce (everything works fine).  I only hit the bug if I let the page load fully before hitting the button.

Comment 9

[Daniel Holbert [:dholbert]]

(hallvors: per comment 8, can you repro if you let the page finish loading before clicking the "View content" button?)

Comment 10

[david]

Hi folks. I did some investigation and there appears to be a jquery/firefox bug where if an iframe is hidden and content within the iframe gets $(...).show(); called on it, that content doesn't actually get shown. Thus, when the iframe gets revealed the content within it is still hidden.

Here's a sample jsfiddle: http://jsfiddle.net/9qkggudz/ In most browsers the "inner" text displays, on firefox it does not.

Do you folks think this is something I should raise a bug against jquery for?

Comment 11

[david]

Scratch that, this seems to have nothing to do with jquery. Here's an updated fiddle with no jquery http://jsfiddle.net/9qkggudz/4/

I tried this in chrome, safari, firefox, firefox nightly, and IE 11. In all of those but the two firefoxes the inner text is displayed.

Comment 12

[Daniel Holbert [:dholbert]]

Are you sure the "display:none" in your jsfiddle actually impacts things? I get the same results if I take that out.

I think the problem might just be that your iframe has no "src" attribute, so it's filled with about:blank, and you're modifying the DOM of about:blank, which is a maybe-iffy thing to do.  If the live Twitter site actually has a src for the corresponding iframe, I suspect the issue shown in your iframe maybe unrelated to the actual live site issue (though I may be wrong).

Comment 13

[Daniel Holbert [:dholbert]]

Actually -- I think part of the problem is due to modifying the iframe's DOM before the iframe has loaded (like, before it actually has its "actual" DOM, because we haven't even started parsing its HTML, for example).

From testing at least, it seems like those immediate-iframe-modifications end up having no effect in Firefox. (They don't show up in DOM inspector in the iframe).

If I delay the div-appending with a setTimeout() (just for illustration purposes), then "inner" does end up being displayed:
http://jsfiddle.net/1nLLv4bh/

Comment 14

[Daniel Holbert [:dholbert]]

(My fiddle there removed the 'display:none' from your iframe, but it still works if I restore that, too:
 http://jsfiddle.net/1nLLv4bh/1/

I think really might need to hold off on any DOM modifications to the iframe until it has fired its 'load' event, or something like that.)

Comment 15

[Daniel Holbert [:dholbert]]

Put another way: if you create an <iframe>, the DOM that you're manipulating before 'load' fires is just a temporary ghost DOM, which gets trashed as soon as onload fires. (in Firefox, at least)

This explains the behavior you're seeing with your jsfiddles, at least. I'm not sure if this is also what's behind the actual bug on the Twitter live site.

Comment 16

[david]

Got it. That's not actually what we're doing on twitter.com, that was just my attempt at creating a useful reproduction case using jsfiddle. That's also probably why I thought it was a jquery issue at first and then changed my mind when I converted it into a jsfiddle.

I'm going to attach another repro case, this time a zipped file with two html files. Load test1.html and it will create an iframe pointing to test2.html. test2.html has two strings one of which gets shown by jquery and one of which gets shown by pure js. The jquery one never shows.

Looks like there's a couple other reports of potentially similar things floating around the internet:
http://stackoverflow.com/questions/24763658/firefox-wont-display-hidden-div-when-shown-using-jquery
http://stackoverflow.com/questions/20478894/jquery-show-fadein-does-not-apply-displayblock-to-a-child-element-inside-a-hidd
http://stackoverflow.com/questions/5903991/jquery-iframe-problems-with-firefox

The root cause looks to me to be potentially related to https://bugzilla.mozilla.org/show_bug.cgi?id=548397

It also looks like at one point jquery was aware of this and implemented a workaround, they've either regressed or the underlying cause of the bug in firefox changed http://bugs.jquery.com/ticket/12904

Comment 17

[david]

Attachment: reproduction example

Comment 18

[Mike Taylor [:miketaylr]]

This looks like the same problem m.futureshop.ca and m.bestbuy.ca had: https://github.com/webcompat/web-bugs/issues/663#issuecomment-72117145

My comment claimed that upgrading to jQuery 1.8.3 would fix the issue, or using .css("display", "block"); instead of .show(). I see that Twitter is suing 1.11.X, so it's possible they did regress (or I was just wrong). I do remember doing testing of the fix though.

Comment 19

[david]

Using jquery 1.8.3 doesn't appear to make a difference to this problem, so it's either not the same thing or is surfacing in a different way from what they fixed before. I'll make the adjustments on twitter.com to use .css instead of .show since that seems like the easiest short term fix for our customers.

Comment 20

[Hallvord R. M. Steen [:hallvors]]

I could reproduce yesterday but didn't have time to debug. Today that link says "account suspended" :-/ I haven't found another video with "sensitive material" warnings. 
(looks some more)
Well, there are Vine videos like https://twitter.com/TheFunnyVines/status/646128759775473664 but that one works for me.. David, is that fix already rolled out?

Comment 21

[david]

Hi Hallvord, the fix hasn't gone out yet. You should be able reproduce using the example files I attached though, that's a much simpler case than looking at the twitter.com one.

Comment 22

[Adam Stevenson [:adamopenweb]]

I'm not able to reproduce this problem in OSX or Win 10 using the link Hallvord provided.

Comment 23

[Hallvord R. M. Steen [:hallvors]]

As a Tech evangelism issue it's correct to close this as fixed - however, there's a test case attached to this bug that demonstrates a difference between Gecko and other engines. Having looked at the test case and the relevant jQuery code I think the underlying issue here is https://bugzilla.mozilla.org/show_bug.cgi?id=548397