542608 - Audio but no video on flash sites with Flashblock installed

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

Visit YouTube or MSNBC and view a video.  There is audio, but no video. 

Reported here:
http://forums.mozillazine.org/viewtopic.php?f=23&t=1719975

I saw at first the same shift in the video, or rather non-movement with scroll, then after turning off OOPP, and back on during testing I lost the video component.

regression shows window:

Works in cset: http://hg.mozilla.org/mozilla-central/rev/e436d3c5a4a6
01/25/10 09:19build
Broken in cset: http://hg.mozilla.org/mozilla-central/rev/795803409745

Leaving https://bugzilla.mozilla.org/show_bug.cgi?id=521426 as the possible problem of losing the video.

Comment 1

[Tyler Downer [He/Him]]

bug 535295 maybe related?

Comment 2

[Benjamin Smedberg]

Is this OOPP-only, or in-process plugins as well?

Comment 3

[u88484]

I can't reproduce this using Flash 10.1.51.45

Comment 4

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #2)
> Is this OOPP-only, or in-process plugins as well?

Does matter if OOPP is on or off, still no video, just audio.

Comment 5

[Jim Jeffery not reading bug-mail 1/2/11]

Well, further testing reveals that the Flashblock addon is likely the problem.  Tested with new profile and was working OK.  Went back to my normal profile and video was not showing, only sound.  Even though the site was allowed through Flashblock, there was no video until I 'disabled' the addon. 

So, don't know if something broke the in-line function of Flashblock, or what.. not a programmer. 

If something thinks this is not a Minefield issue, but rather an update is required in Flashblock, feel free to close as INVALID.

Comment 6

[IU]

This is looks like bug 542447, which got duped to bug 542447.

I'm not sure the duping was correct, so I'm waiting for bug 540604 to verify.

Comment 7

[IU]

Gaah!!!  Gotta proofread.

This looks like bug 542447, which got duped to bug 542263.

I'm not sure the duping was correct, so I'm waiting for bug 540604 to verify.

Comment 8

[IU]

Or maybe not.  Never mind.

Comment 9

[Philip Chee]

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e436d3c5a4a6&tochange=795803409745

Only one changeset:
http://hg.mozilla.org/mozilla-central/rev/795803409745
Null-check the root pres context result. Unregister the plugin frame earlier, at Stop instead of Destroy time. b=521426 r=roc

Bug 521426 (Crash [@ PL_DHashTableEnumerate] called from nsRootPresContext::GetPluginGeometryUpdates because nsPresContext::RootPresContext() can return non-nsRootPresContext object)

With Flashblock actively blocking youtube, clicking on the flashblock placeholder allows the video to play normally. With youtube whitelisted the audio is heard but the video is not seen. The flashblock content XBL uses a DOM UIEvent to send a whitelist signal to chrome. The flashblock chrome code then checks the whitelist:

	checkLoadFlash : function (e) {
		if(!gFlashblockEnabled || Flashblock.checkWhitelist(e.target.location))
			e.preventDefault();
		e.stopPropagation();
	},

So somehow the time taken to check the whitelist interferes with the timing and the video does not paint.

If I use Stylish (or nsIStylesheetService) to change the style of the youtube embed
@-moz-document domain(youtube.com) {
  #movie_player {
    display: block;
  }
}
The video reappears. It doesn't matter what I change the display: to I just need to toggle it and the flashplayer appears, the video  becomes visible and restarts from the beginning.  I would guess that toggling the display style causes a reflow and reinits the flashplayer.

Comment 10

[IU]

This bug also causes youtube videos to scroll as the page is scrolled, instead of remaining fixed in place.

Comment 11

[IU]

...but only if the site is not whitelisted in flashblock and a user presses the flashblock icon to start playback.

Comment 12

[Philip Chee]

Which doesn't make any sense, since once the flash object is re-inserted into the DOM flashblock is out of the picture.

Comment 13

[Benjamin Smedberg]

I think that flashblock is important enough this needs to block 1.9.3alpha1.

Comment 14

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

We need to always register the frame when there's a widget (balancing the
condition for when we unregister), not just the first time when creating
the widget.  (Flashblock caused a re-instantiation of a stopped plugin using
the existing frame/widget.)

Comment 15

[Mats Palmgren (inactive)]

Test builds:
https://build.mozilla.org/tryserver-builds/[e-mail]-542608-patch1/

Comment 16

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #15)
> Test builds:
> https://build.mozilla.org/tryserver-builds/[e-mail]-542608-patch1/

All seems good here..just tested on several sites, with and without flashblock, and all appears normal.

Comment 17

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

Why is this marked 1.9.2-unaffected? As far as I can tell it should affect 1.9.2.

Thanks Mats! I guess we should be able to have a test here.

Comment 18

[Boris Zbarsky [:bzbarsky]]

> Why is this marked 1.9.2-unaffected? 

Probably because bug 521426 hasn't landed on 1.9.2 yet.  This should be marked the same way that bug is, imo.

Comment 19

[Mats Palmgren (inactive)]

Yes, my plan was to merge this fix with the 1.9.2 patch on bug 521426
and asking for approval on that, but this works too.

Comment 20

[Mats Palmgren (inactive)]

http://hg.mozilla.org/mozilla-central/rev/8ad351bc774b

Comment 21

[Mats Palmgren (inactive)]

Will wait another day or two to allow the regression fix to bake.

Comment 22

[Jim Jeffery not reading bug-mail 1/2/11]

I can verify that this is fixed on m-c with the latest hourly:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100128 Minefield/3.7a1pre ID:20100128145729

cset: http://hg.mozilla.org/mozilla-central/rev/8ad351bc774b

Comment 23

[Philip Chee]

<http://forums.mozillazine.org/viewtopic.php?p=8566275#p8566275>

Users report issue with Flashblock is fixed in the latest hourly builds. Thanks guys for the quick response.

Comment 24

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 424024 [details] [diff] [review]
Patch rev. 1

a1922=beltzner

Comment 25

[Mats Palmgren (inactive)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a32a618eb663
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/7723073d61b2

Comment 26

[Tobias (:Tobbi) Markus]

I can VERIFY FIXED with latest nightly on Win32 Vista.

Comment 27

[Al Billings [:abillings - ex-MoCo]]

Running 1.9.2.0 here on XP, I cannot reproduce this issue using Flashblock 1.5.11.2. If I whitelist youtube and watch videos there, they will play fine (just as they do if I don't whitelist but select the flashblock button on the video when it shows up). 

Have we actually seen this problem in Firefox 3.6 at all?

Comment 28

[Mats Palmgren (inactive)]

Al, this bug was a regression fix for bug 521426 which never landed on
1.9.2 by itself.  Both patches together on 1.9.2 (comment 25).

Comment 29

[Al Billings [:abillings - ex-MoCo]]

Thanks, Mats. Does this mean that there is no scenario to repro the bug on 1.9.2 since the original regression by itself?

Comment 30

[Mats Palmgren (inactive)]

Not with a nightly build, no.

Comment 31

[Henrik Skupin (:whimboo) [⌚️UTC+1]]

I was able to reproduce this bug with an older Minefield build. A recent build on trunk doesn't show this problem. Even the candidate build 3 of Firefox 3.6.2 looks good. Marking as verified on 1.9.2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2