Closed Bug 805331 Opened 7 years ago Closed 7 years ago

The Facebook sidebar stops the rendering of youtube plugins

Categories

(Core :: Layout, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla19
Tracking Status
firefox17 - unaffected
firefox18 + verified
firefox19 + verified

People

(Reporter: Ehsan, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(3 files, 3 obsolete files)

Attached image Screenshot
This is pretty serious.  As I had the sidebar open, I went to youtube and started to watch a video, but the plugin content remained black as the sound started.  Closing the sidebar brought back the video and the UI.  When the sidebar is open, right clicking the plugin opens the context menu in the wrong location (see the screenshot)
I've a feeling this is similar to the recent focus bug we had (not looking it up right now).

You can reproduce by bookmarking a youtube video, and setting the bookmark to open in sidebar (you might only be able to do that from the bookmarks sidebar).  Then open a youtube video in a tab, and open the bookmark (it should open in the left sidebar).  

Results for me is a black content areas and context menu's opening in the wrong place.  Then, just open a new blank tab, and the content in the sidebar starts playing correctly.

Essentially, this is a bug caused by two html content area's being visible in the window, with both having a flash plugin, something that seems to have issues in general.

This also may explain bug 801842.
Severity: normal → critical
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
Maybe we should set allowplugins=false on the social sidebar.
Dupe of bug 804240? Note that this doesn't affect beta (Ehsan, can you verify?), so DLBI could be the cause.

I didn't think FB's sidebar has any flash content loaded, I'll check.
(In reply to :Felipe Gomes from comment #3)

> I didn't think FB's sidebar has any flash content loaded, I'll check.

I think that the sidebar may be loading content, which can include flash videos, for the flyout.  That is what it does in the website, and I think also for their messenger product.
(In reply to Jared Wein [:jaws] from comment #2)
> Maybe we should set allowplugins=false on the social sidebar.

lets bring this up with Pam, it may be ok to do that on the sidebar, but I think we'll still have the issue crop up with the flyout.
FTR, I checked and FB's sidebar had no plugins loaded, and I can still reproduce this bug (youtube video stops rendering).

Not that it wouldn't be a good idea to disallow plugins on the sidebar, but just mentioning that although the STR from comment 1 mentions having two plugins loaded, it's not required for this bug to happen (although it may be an easier testcase if someone doesn't want to use the Social integration to reproduce this)
Can you give me a way to reproduce this that doesn't require me joining Facebook?
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7)
> Can you give me a way to reproduce this that doesn't require me joining
> Facebook?

I have to retract comment 1, completely disabling socialapi and rerunning that test shows that the problem does not happen.

I'll see if I can create a non-facebook test
(In reply to :Felipe Gomes from comment #3)
> Dupe of bug 804240? Note that this doesn't affect beta (Ehsan, can you
> verify?), so DLBI could be the cause.

Yeah they're the same, but I'll dupe the other way around since roc is here.  :-)
Duplicate of this bug: 804240
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7)
> Can you give me a way to reproduce this that doesn't require me joining
> Facebook?

No need to join Facebook, just set social.enabled to true.  The sidebar will open with a login link.  Then go to youtube and the bug will reproduce.  I don't think that it has anything to do with the content of the sidebar.

Note that I couldn't reproduce on Linux.  This could be Mac-only.  Have not tried Windows yet.
Also happens on Windows for me. I just discovered that it's not the sidebar being visible that causes the problem, it's the splitter between the main content area and the sidebar. So a simpler way to reproduce the problem (at least on my Windows machine)

1. Open a youtube video that uses Flash
2. Open error console
3. top.opener.document.getElementById("social-sidebar-splitter").hidden=false
I'm having trouble reproducing this in a Windows 7 debug build. The sidebar opens, but the video continues to play fine.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #13)
> I'm having trouble reproducing this in a Windows 7 debug build. The sidebar
> opens, but the video continues to play fine.

I can repro this in a win7 debug build.  FWIW, I'm using a scratchpad in the "browser" content and executing:

  document.getElementById("social-sidebar-splitter").hidden=false

As soon as I execute that, I see many "Double UnblockOnLoad!?", assertions, followed by many "More UnblockOnLoad() calls than BlockOnLoad() calls; dropping call: 'Not reached' ...nsDocument.cpp, line 6870

As soon as I toggle hidden back to true, it shows up.  Also note that the repro does *not* show any sidebar for me - no idea why it did for you.

Exact same result in an opt build, except obviously for the assertions (but the assertions looks like they may be relevant)
I toggled social.enabled in about:config.

I'm building on Mac now to see if that helps.
Seeing this consistently on Win7 and I can reproduce it on Mac, too. Definitely a blocker for broader deployment.
Duplicate of this bug: 805035
bug 804240 also mentions this affecting v.mozilla.com (flash)
(In reply to comment #18)
> bug 804240 also mentions this affecting v.mozilla.com (flash)

I can't reproduce on v.mozilla.com.
Does this affect Firefox 19?
Both of the following comments suggest FF17 is unaffected:
https://bugzilla.mozilla.org/show_bug.cgi?id=804240#c2
https://bugzilla.mozilla.org/show_bug.cgi?id=805035#c4

This bug and these comments suggest FF18/19 are affected:
https://bugzilla.mozilla.org/show_bug.cgi?id=804240#c5
https://bugzilla.mozilla.org/show_bug.cgi?id=805035#c3

Since Anthony is having trouble reproducing (https://bugzilla.mozilla.org/show_bug.cgi?id=804240#c4), Juan - can you give this a go? We'd like to gain clarity on what versions are affected, if this is a regression, when it regressed, and what versions of Flash or Platforms are affected (if it isn't just all).
(feel free to kick this to somebody else in QA, or SoftVision to test Sunday night as a last resort, if you're caught up in deploying the stub installer test)
Yeah I can't reproduce the youtube case on 17 either.
(In reply to Ehsan Akhgari [:ehsan] from comment #23)
> Yeah I can't reproduce the youtube case on 17 either.


It definitely wasn't working for me this morning, I tried several times (on 17) but now it seems to be fixed. (yay!)
(In reply to Alex Keybl [:akeybl] from comment #22)
> (feel free to kick this to somebody else in QA, or SoftVision to test Sunday
> night as a last resort, if you're caught up in deploying the stub installer
> test)

I've spent a good hour on a couple of machines running Win7 and a couple of versions of Flash (11.4x and 11.5x), but I wasn't able to reproduce the problem. I'll get other people to help find a regression range.

Also, ping me if you need testing accounts for FB (and Zynga).
I'm on  mac w/17 and the embedded videos from youtube are disabled again.  
For example, on adweek, here: http://bit.ly/RuBWPG
there youtube videos that don't appear unless I turn off the social api feature. If the feature is on, the videos don't even show.  If I turn it off they appear, and if I turn it back on then the video box is there but inactive.
I am still unable to reproduce.
I am able to reproduce this on Windows 7 using the latest Nightly.
(In reply to comment #26)
> I'm on  mac w/17 and the embedded videos from youtube are disabled again.  
> For example, on adweek, here: http://bit.ly/RuBWPG
> there youtube videos that don't appear unless I turn off the social api
> feature. If the feature is on, the videos don't even show.  If I turn it off
> they appear, and if I turn it back on then the video box is there but inactive.

Hmm, this definitely seems to be the exact same behavior that I'm seeing.  I thought that maybe this has something to do with the window size, but apparently it doesn't.  roc, if you want I have a Windows box at the office which you can rdp into and debug this.  Please ping me if you need me to set it up for you.
I can reproduce this on Mac Nightly 19 and Aurora 18, but not Beta 17. I'm using Flash Beta 11.5.500.80.
This bug is not YouTube-specific. I see the same problem on Vimeo.

If I open the sidebar while a video is playing, the video freezes but the audio continues to play. If I then close the sidebar, the video starts playing (in sync with the audio).
Yep. A regression range would be really swell here, particularly because an Aurora regression range with an obvious culprit would save us from worrying so much about beta. QA - any luck? Roc, have you found a way to reproduce it?
This bug first appeared in Nightly 2012-10-14. Here is the regression range between 10-13 to 10-14:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=57304bbf9c0e&tochange=942ed5747b63

bug 626245 looks suspicious because it is related to painting and plugins.
In addition we are looking for a patch that was uplifted to Aurora and bug 626245 meets that criteria as well.
Blocks: 626245
I wasn't able to reproduce on Fx17(latest beta), but I was able to reproduce easily with the example in comment #26 using Aurora, and I could confirm the regression range Chris found.
Assignee: nobody → roc
Keywords: regression
Duplicate of this bug: 806658
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #27)
> I am still unable to reproduce.

We discussed this in the 10/30 platform meeting - Mats, can you help here since roc's not able to repro?
Assignee: roc → matspal
Any improvement with 11.5.500.104?
Assignee: matspal → roc
Severity: critical → normal
OS: All → Mac OS X
Hardware: All → x86
Version: Trunk → unspecified
Attached patch fix (obsolete) — Splinter Review
Attachment #676981 - Flags: review?(matspal)
roc, did you attach the wrong patch?
(Resetting the flags)
OS: Mac OS X → All
Hardware: x86 → All
The AudioBuffer changes in this patch are unrelated to the displaylist changes at the bottom which is relevant.
Happens for me too on Firefox 19 on Windows but not on same builds on Linux
Attached patch fix v2 (obsolete) — Splinter Review
Sorry about the extra junk in the patch. It was late :-).
Attachment #676981 - Attachment is obsolete: true
Attachment #676981 - Flags: review?(matspal)
Attachment #677187 - Flags: review?(matspal)
Attachment #677187 - Attachment is patch: true
Comment on attachment 677187 [details] [diff] [review]
fix v2

This will consider transform items as leaf items, but that should be fine.
No, I should actually fix that.
Attachment #677187 - Attachment is obsolete: true
Attachment #677187 - Flags: review?(matspal)
Component: SocialAPI → Layout
Product: Firefox → Core
Comment on attachment 677212 [details] [diff] [review]
Bug 805331. Part 1: refactor nsDisplayList::GetList

I get numerous assertions on startup with a fresh profile:
###!!! ASSERTION: Children must have same reference frame: 'mList.IsEmpty() || mList.GetBottom()->ReferenceFrame() == ReferenceFrame()', file layout/base/nsDisplayList.h, line 2082
Attachment #677212 - Flags: review?(matspal) → review-
Attached patch Part 1 v2Splinter Review
Fixed the assertions. When one of the display items involved is an nsDisplayClip, the reference frame is null, so just ignore that case.
Attachment #677212 - Attachment is obsolete: true
Attachment #677321 - Flags: review?(matspal)
Comment on attachment 677213 [details] [diff] [review]
Bug 805331. Part 2

In the check-in comment, delete the first "treat"?
"Only treat chrome display items that are leaves should be treated as especially opaque."
Attachment #677213 - Flags: review?(matspal) → review+
Attachment #677321 - Flags: review?(matspal) → review+
We'll need these on Aurora.
https://hg.mozilla.org/mozilla-central/rev/bdec21b0103c
https://hg.mozilla.org/mozilla-central/rev/5c88f84c75d6

Should this have a test?
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Yes. I should be able to write a test for this.
Verified fixed in Nightly 19.0a1 (2012-11-04).
Status: RESOLVED → VERIFIED
Comment on attachment 677321 [details] [diff] [review]
Part 1 v2

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 626245
User impact if declined: Flash sometimes doesn't work when the social sidebar is open (i.e., critical)
Testing completed (on m-c, etc.): a couple of days on m-c
Risk to taking this patch (and alternatives if risky): Low risk
String or UUID changes made by this patch: none
Please consider this an approval request for both patches.
Attachment #677321 - Flags: approval-mozilla-aurora?
Comment on attachment 677321 [details] [diff] [review]
Part 1 v2

Much needed patch , approving for aurora
Attachment #677321 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I see that this is set to be fixed with "Mozilla 19." Does this mean YouTube videos won't be able to play when the sidebar is open, when users are on Firefox 17 and 18? Or will this be fixed for those users too? May be a stupid question, but just making sure.
(In reply to Laura Forrest from comment #59)
> I see that this is set to be fixed with "Mozilla 19." Does this mean YouTube
> videos won't be able to play when the sidebar is open, when users are on
> Firefox 17 and 18? Or will this be fixed for those users too? May be a
> stupid question, but just making sure.

This is fixed for 19. It will be fixed for 18 when the patch gets uplifted to Aurora, which it now has approval for. This bug does not exist in 17.
(In reply to Jared Wein [:jaws] from comment #60)
> (In reply to Laura Forrest from comment #59)
> > I see that this is set to be fixed with "Mozilla 19." Does this mean YouTube
> > videos won't be able to play when the sidebar is open, when users are on
> > Firefox 17 and 18? Or will this be fixed for those users too? May be a
> > stupid question, but just making sure.
> 
> This is fixed for 19. It will be fixed for 18 when the patch gets uplifted
> to Aurora, which it now has approval for. This bug does not exist in 17.

Got it -- thanks for the clarity.
The problem was simple. On Aurora, mReferenceFrame was left uninitialized in nsDisplayItem's constructor if mFrame is null.
https://tbpl.mozilla.org/?tree=Try&rev=2abdb8673be4
We still get assertion failures. This is because the complete fix for bug 800041 hasn't landed on Aurora.

I'll just remove the assertion for Aurora.
I have found a regression range for this issue. As long as Social API was implemented since Nightly 19 (18/10/2012) it looks like this issue had reproduced since the beginning until Nightly 19 (03.11.2012)

First good nightly: 2012-11-03
Last bad nightly: 2012-11-02

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2718739a1c83&tochan
ge=556b9cfb269f

In addition, I found this issue verified fixed for:

FF 18.b7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0(20121231071231) 

Aurora 19
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130102 Firefox/19.0(20130102042016)
(In reply to MarioMi from comment #67)

Sorry for invalid pushlog link. Here is the correct one:

Last bad nightly: 2012-11-02
First good nightly: 2012-11-03

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2718739a1c83&tochange=556b9cfb269f
You need to log in before you can comment on or make changes to this bug.