805331 - The Facebook sidebar stops the rendering of youtube plugins

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[(no longer active)]

Attachment: 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)

Comment 1

[Shane Caraveo (:mixedpuppy)]

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.

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Maybe we should set allowplugins=false on the social sidebar.

Comment 3

[:Felipe Gomes (needinfo for replies!)]

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.

Comment 4

[Shane Caraveo (:mixedpuppy)]

(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.

Comment 5

[Shane Caraveo (:mixedpuppy)]

(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.

Comment 6

[:Felipe Gomes (needinfo for replies!)]

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)

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you give me a way to reproduce this that doesn't require me joining Facebook?

Comment 8

[Shane Caraveo (:mixedpuppy)]

(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

Comment 9

[(no longer active)]

(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.  :-)

Comment 11

[(no longer active)]

(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.

Comment 12

[:Felipe Gomes (needinfo for replies!)]

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

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm having trouble reproducing this in a Windows 7 debug build. The sidebar opens, but the video continues to play fine.

Comment 14

[Mark Hammond [:markh] [:mhammond]]

(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)

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I toggled social.enabled in about:config.

I'm building on Mac now to see if that helps.

Comment 16

[Johnathan Nightingale [:johnath]]

Seeing this consistently on Win7 and I can reproduce it on Mac, too. Definitely a blocker for broader deployment.

Comment 18

[:Gavin Sharp [email: [e-mail]]]

bug 804240 also mentions this affecting v.mozilla.com (flash)

Comment 19

[(no longer active)]

(In reply to comment #18)
> bug 804240 also mentions this affecting v.mozilla.com (flash)

I can't reproduce on v.mozilla.com.

Comment 20

[Josiah Bruner [:jsbruner]]

Does this affect Firefox 19?

Comment 21

[Alex Keybl [:akeybl]]

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).

Comment 22

[Alex Keybl [:akeybl]]

(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)

Comment 23

[(no longer active)]

Yeah I can't reproduce the youtube case on 17 either.

Comment 24

[Tara (musingt)]

(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!)

Comment 25

[juan becerra [:juanb]]

(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).

Comment 26

[Tara (musingt)]

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.

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I am still unable to reproduce.

Comment 28

[Mike Conley (:mconley) (:⚙️)]

I am able to reproduce this on Windows 7 using the latest Nightly.

Comment 29

[(no longer active)]

(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.

Comment 30

[Chris Peterson [:cpeterson]]

I can reproduce this on Mac Nightly 19 and Aurora 18, but not Beta 17. I'm using Flash Beta 11.5.500.80.

Comment 31

[Chris Peterson [:cpeterson]]

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).

Comment 32

[Johnathan Nightingale [:johnath]]

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?

Comment 33

[Chris Peterson [:cpeterson]]

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.

Comment 34

[Kevin Brosnan [Ex-Mozilla]]

In addition we are looking for a patch that was uplifted to Aurora and bug 626245 meets that criteria as well.

Comment 35

[juan becerra [:juanb]]

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.

Comment 37

[Alex Keybl [:akeybl]]

(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?

Comment 38

[Arthur K. (he/him)]

Any improvement with 11.5.500.104?

Comment 39

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

Comment 40

[Mats Palmgren (inactive)]

roc, did you attach the wrong patch?

Comment 41

[(no longer active)]

(Resetting the flags)

Comment 42

[Benjamin Smedberg]

The AudioBuffer changes in this patch are unrelated to the displaylist changes at the bottom which is relevant.

Comment 43

[Daniel Desira]

Happens for me too on Firefox 19 on Windows but not on same builds on Linux

Comment 44

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix v2

Sorry about the extra junk in the patch. It was late :-).

Comment 45

[Timothy Nikkel (:tnikkel)]

Comment on attachment 677187 [details] [diff] [review]
fix v2

This will consider transform items as leaf items, but that should be fine.

Comment 46

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No, I should actually fix that.

Comment 47

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Bug 805331. Part 1: refactor nsDisplayList::GetList

Comment 48

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Bug 805331. Part 2

Comment 49

[Mats Palmgren (inactive)]

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

Comment 50

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 1 v2

Fixed the assertions. When one of the display items involved is an nsDisplayClip, the reference frame is null, so just ignore that case.

Comment 51

[Mats Palmgren (inactive)]

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."

Comment 52

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bdec21b0103c
https://hg.mozilla.org/integration/mozilla-inbound/rev/5c88f84c75d6

Comment 53

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We'll need these on Aurora.

Comment 54

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/bdec21b0103c
https://hg.mozilla.org/mozilla-central/rev/5c88f84c75d6

Should this have a test?

Comment 55

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes. I should be able to write a test for this.

Comment 56

[Chris Peterson [:cpeterson]]

Verified fixed in Nightly 19.0a1 (2012-11-04).

Comment 57

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 58

[bhavana bajaj [:bajaj]]

Comment on attachment 677321 [details] [diff] [review]
Part 1 v2

Much needed patch , approving for aurora

Comment 59

[Laura Forrest]

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.

Comment 60

[Jared Wein [:jaws] (please needinfo? me)]

(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.

Comment 61

[Laura Forrest]

(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.

Comment 62

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/8ff55e73442e
https://hg.mozilla.org/releases/mozilla-aurora/rev/bac585f0c320

Comment 63

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Backed out since these patches caused assertions on Aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/7ad8200e00ec

Comment 64

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 65

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 66

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/2ed2cc2f321b
https://hg.mozilla.org/releases/mozilla-aurora/rev/af90ef6d15d4

Comment 67

[Mihai Morar, (:MihaiMorar)]

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)

Comment 68

[Mihai Morar, (:MihaiMorar)]

(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

Comment 69

[Mihai Morar, (:MihaiMorar)]

This is the correct pushlog.

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-11-02&enddate=2
012-11-03