618487 - Starting Nightly Win32 20101208 Trunk Build Divx Web Player Videos won't play on Vidbux.com and Vidxden.com and Movshare.net

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[rob64rock]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101210 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101210 Firefox/4.0b8pre

I'm having trouble getting Divx Web Player to play videos on Nightly Win32 20101208 Trunk Build and Later. Once the page is fully loaded I hit the play button on the Divx Web Player and instead of connecting then buffering the video the Divx Web Player turns into a black box with no Divx Web Player controls visible. I had to revert back to Nightly Win32 20101207 Trunk Build to get the Divx Web Player Videos work again on VidBux.com and VidxDen.com.

Reproducible: Always

Steps to Reproduce:
1.Use Nightly Win32 20101208 Trunk Build or Later. With Divx Web Player 1.5 or 2.0 installed.
2.Go to: http://www.vidbux.com/4okb2x8jle44/burn.notice.s04e16.hdtv.xvid-fever.avi.html or http://www.vidxden.com/ccd5oo09y57e/burn.notice.s04e16.hdtv.xvid-fever.avi.html
3.Once the page is fully loaded hit the play button on the Divx Web Player.
Actual Results:  
Instead of connecting then buffering the video the Divx Web Player turns into a black box with no Divx Web Player controls visible. With HWA disabled the Divx Web Player turns into a white box with no Divx Web Player controls visible.

Expected Results:  
Divx Web Player should say connecting then start buffering the video and eventually start playing the video.

Tested on fresh install with no extensions. Also tested with disabling HWA and "javascript.options.methodjit.content".
Only reverting back to Nightly Win32 20101207 Trunk Build made the Divx Web Player Videos work again on VidBux.com and VidxDen.com. 
Note: VidxDen.com and VidBux.com are riddled with AD's so, you might want to test with Adblock Plus extension or Adblocking software. Using them or not neither solves the problem, so it' your choice.

Comment 1

[Alice0775 White]

Confirmed on:Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101209 Firefox/4.0b8pre ID:20101209030340

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/9c99f0193930
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre ID:20101207124922
Fails:
http://hg.mozilla.org/mozilla-central/rev/b1b57869cb43
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre ID:20101207132224
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9c99f0193930&tochange=b1b57869cb43

Regressed by:
b1b57869cb43	Steven Michaud — Bug 594482 - Java applets broken with content policies. r=josh,bsmedberg a=blocking2.0BetaN+

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Testing on OS X, it's almost impossible to figure out which of these videos are actually DivX videos.  Please try to come up with more straightforward testcases.

Comment 3

[rob64rock]

(In reply to comment #2)
> Testing on OS X, it's almost impossible to figure out which of these videos are
> actually DivX videos.  Please try to come up with more straightforward
> testcases.

The videos are actually Xvid encoded AVI files that VidBux.com and VidxDen.com happen to stream using the Divx Web Player. The links I provided are straightforward that I copy from urlbar after going through few AD's redirects pages. That why is suggested to test with ADBlock Plus extension installed or something similar or not, your choice.
Here are some more links to videos that are streamed with Divx Web Player on those sites: http://www.vidbux.com/pjavlltu895z/smallville.s10e11.hdtv.xvid-2hd.avi.html or http://www.vidxden.com/tlrzhltp01c1/smallville.s10e11.hdtv.xvid-2hd.avi.html
If you want to go through all AD's redirect pages to get to the links I provided go here: http://www.fastpasstv.com/new/tv/ , Select a TV show and choose the links that indicate "VidBux (Divx)" or "VidxDen (Divx)", some of the links that indicate "(Divx)" are actually MVK encoded videos which only play if you have Divx Web Player 2.0 or higher. The video links I provided will play on Nightly Win32 20101207 Trunk Build using Divx Web Player 1.5 or higher.

Comment 4

[rob64rock]

(In reply to comment #2)
> Please try to come up with more straightforward
> testcases.

It appears that this bug also happens on Movshare.net
Links here:
http://www.movshare.net/video/47h0mo0muklih and http://www2.movshare.net/player.php?v=riuqeh29ayd8s

Comment 5

[DB Cooper]

Can confirm on movshare.net as well. 

http://www.movshare.net/video/s6htt2u58kvnj

Stagevu seems to be OK, as does VeeHD.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix/workaround

I can reproduce this bug on Windows with the URLs from comment #4 and
comment #5 (in the 2010-12-08-03-mozilla-central nightly and
following).  I can't reproduce it on OS X.

Here's a patch that seems to fix the problem on Windows.  And here's a
tryserver build made from my patch.  Please test it as thoroughly as
possible and let us know your results.

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-550287ad52ed/try-w32/firefox-4.0b9pre.en-US.win32.zip

After my patch for bug 594482 landed, the timing of the first call to
the plugin's NPP_SetWindow() changed for this bug's testcases -- it
was no longer made from nsPluginHost::DoInstantiateEmbeddedPlugin().
The reason is that (at this point) the plugin is still "hidden"
(thanks to its CSS style or an EMBED tag's HIDDEN attribute).  Not
getting this call to NPP_SetWindow() (apparently) confuses the plugin,
and stops it displaying correctly.

A "hidden" plugin shouldn't need calls to NPP_SetWindow().  So this
bug is really in the DivX plugin and/or in the HTML code used to
instantiate it.

But my patch for bug 594482 (in effect) added IsHidden() checks to a
number of calls to NPP_SetWindow() that didn't have them before (in
nsPluginHost::DoInstantiateEmbeddedPlugin() and elsewhere).  These
checks weren't needed to fix the specific problem that my bug 594482
patch was intended to fix.  And I can't see how getting rid of them
would actually cause harm -- especially since that just restores
previous behavior.

So that's what my patch does (by adding an aCheckIsHidden parameter to
nsObjectFrame::CallSetWindow()).

Comment 7

[rob64rock]

(In reply to comment #6)
> Created attachment 498245 [details] [diff] [review]
> Fix/workaround
> 
> I can reproduce this bug on Windows with the URLs from comment #4 and
> comment #5 (in the 2010-12-08-03-mozilla-central nightly and
> following).  I can't reproduce it on OS X.
> 
> Here's a patch that seems to fix the problem on Windows.  And here's a
> tryserver build made from my patch.  Please test it as thoroughly as
> possible and let us know your results.
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-550287ad52ed/try-w32/firefox-4.0b9pre.en-US.win32.zip
> 
After testing the tryserver build with patch the problems seems to be solved and I longer having problems on those sites playing videos using the Divx Web Player.
Thank you, so very much and Happy Holidays to all the Mozilla devs working so hard to bring us the best Firefox browser ever.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 498245 [details] [diff] [review]
Fix/workaround

Landed on trunk:
http://hg.mozilla.org/mozilla-central/rev/1ff07ed94d79