Last Comment Bug 569104 - [OOPP] Cnet TV Gecko v.14 flash player does not work with OOPP
: [OOPP] Cnet TV Gecko v.14 flash player does not work with OOPP
Status: RESOLVED WORKSFORME
[bugday0601][oopp-watchlist]
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: 1.9.2 Branch
: x86 Windows 7
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://download.cnet.com/VLC-Media-Pl...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-29 20:54 PDT by Frank Mar
Modified: 2011-03-10 01:54 PST (History)
27 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
needed
wanted


Attachments

Description Frank Mar 2010-05-29 20:54:52 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100527 Firefox/3.6.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100527 Firefox/3.6.4

Watching a video on the download section of Cnet, is plain grey, and does not play. on other browsers it works perfectly, pre me downloading 3.6.4 it worked

Reproducible: Always

Steps to Reproduce:
1.Go to download page with a video review
2.Scroll down to video
3.Attempt to play video 
Actual Results:  
video did not play, grey screen

Expected Results:  
started loading a video and playing

right clicking the video the top option is "CNET TV 3 Gecko v.14"
Comment 1 Ria Klaassen (not reading all bugmail) 2010-05-30 00:05:02 PDT
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100529 Minefield/3.7a5pre

Only with dom.ipc.plugins.enabled to true.
Comment 2 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2010-05-30 04:42:14 PDT
VLC? We don't whitelist VLC by default in 3.6.4.
Comment 3 XtC4UaLL [:xtc4uall] 2010-05-30 06:21:26 PDT
(In reply to comment #2)
> VLC? We don't whitelist VLC by default in 3.6.4.

Heh, it's not about using VLC as plugin in OOPP, but rather about the CNet Video review about VLC ;-).

i can confirm the issue using 1.9.2.4 (build 6) & 1.9.3 (build 20100529) + Flash 10.1.53.60 in OOPP. IPP is okay.
Comment 4 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2010-06-01 07:55:30 PDT
I've done some investigation into this on CNet's website.  The video linked in this bug and videos which appear on pages from CNet's Downloads tab are using an older version of CNet's video player than that of the CNet TV tab.

Download Tab: CNET TV3 Gecko v.14
CNet TV Tab: CNET TV3 Gecko v.2

Videos played using v.2 work, videos played using v.14 do not.
Comment 5 Mike Beltzner [:beltzner, not reading bugmail] 2010-06-01 10:20:24 PDT
Same as / similar to bug 563361? That one seems to be about how OOPP works using object tag but not an embed tag - perhaps that's the same difference between v.2 and v.14 of the video player?
Comment 6 christian 2010-06-01 10:42:31 PDT
Download tab is a div that gets a dynamic object tab inserted:

<object height="337" width="512" data="/av/video/gecko/alpha/player.swf" type="application/x-shockwave-flash" id="GeckoVideoPlayer1"><param value="high" name="quality"><param value="always" name="allowScriptAccess"><param value="transparent" name="wMode"><param value="true" name="swLiveConnect"><param value="opaque" name="wmode"><param value="#666666" name="bgcolor"><param value="noscale" name="scale"><param value="lt" name="salign">
[...]
</object>

Looks like CNet TV is pretty much the same (div that then gets an object tag inserted:

<object height="300" width="812" data="http://cnettv.cnet.com/av/video/cnettv/4/20100524/player.swf" type="application/x-shockwave-flash" id="GeckoVideoPlayer1"><param value="high" name="quality"><param value="always" name="allowScriptAccess"><param value="opaque" name="wMode"><param value="true" name="swLiveConnect"><param value="opaque" name="wmode"><param value="#000000" name="bgcolor"><param value="noscale" name="scale"><param value="lt" name="salign"><param value="true" name="allowFullScreen">
[...]
</object>
Comment 7 MrX1980 2010-06-01 11:53:48 PDT
Confirmed with:
- Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:1.9.2.4) Gecko/20100527 Firefox/3.6.4
- Adobe Flash Player 10,1,53,60 (10.1rc6)
- Gainward GeForce GT 240 Golden Sample
- nVIDIA ForceWare 197.44 (6.14.11.9744)
Comment 8 Daniel Veditz [:dveditz] 2010-06-02 10:42:25 PDT
possibly blocking 1.9.2.4 so we'll mark it so to keep this tracked. Otherwise it'll get fixed in 1.9.2.5
Comment 9 Jim Mathies [:jimm] 2010-06-02 11:26:03 PDT
I've been trying to diagnose this, it seems similar to bug 563361. There is a pre-roll advertisement video associated with this that seems to load, and then shutdown. Then the video loads up. Neither the ad, or the video play. Looking at the logs and stepping through a bit, I'm currently at a loss as to what might be the cause.
Comment 10 christian 2010-06-02 16:06:24 PDT
I pinged CNet about this issue.
Comment 11 Mike Beltzner [:beltzner, not reading bugmail] 2010-06-03 07:47:45 PDT
Is this limited to download.com videos, or a subset of the CNet video offerings?
Comment 12 Jim Mathies [:jimm] 2010-06-03 08:18:15 PDT
(In reply to comment #11)
> Is this limited to download.com videos, or a subset of the CNet video
> offerings?

Seems to be specific to older editor's review videos. I've found some new review videos work just fine. Older one's don't, likely due to the upgraded video player mentioned in comment 4.

If you start here, you can click through and find some videos working, some not - 

http://download.cnet.com/windows/3150-20_4-0.html?listType=2&sort=editorsRating+asc&tag=rb_content;contentNav
Comment 13 mattburles 2010-06-03 22:46:16 PDT
any idea of what the problem is and when it will be fixed if there is a problem?
Comment 14 Mike Beltzner [:beltzner, not reading bugmail] 2010-06-04 05:35:09 PDT
Right now it's unclear if this is a problem with our code, or a problem with the CNet TV3 v.14 video player that our code has exposed.

Christian - have you heard back from CNet yet? We need to escalate and then determine if this is limited to that player, or affecting other players.

Matt Burles - are you also only seeing this on older editor review videos on CNet via the Download tab in their UI?
Comment 15 mattburles 2010-06-04 06:09:14 PDT
(In reply to comment #14)
> Right now it's unclear if this is a problem with our code, or a problem with
> the CNet TV3 v.14 video player that our code has exposed.
> 
> Christian - have you heard back from CNet yet? We need to escalate and then
> determine if this is limited to that player, or affecting other players.
> 
> Matt Burles - are you also only seeing this on older editor review videos on
> CNet via the Download tab in their UI?

Yes it is only occuring on older videos so I believe this is part of the player and not firefox own code. I don't see how this blocks the release of 3.6.4 either when majority of people don't go to this site to view videos anyway.. If this was happening on YouTube which it isn't than I would be concerned.
Comment 16 christian 2010-06-04 14:47:32 PDT
I don't see how you can make the conclusions in comment 14 yet. First, we are not sure if it is the player's problem. Second, to users, it will appear as if 3.6.4 broke them in any case. Third, Cnet.com (which downloads.com redirects to) is #35 in Gogole's top 1000 (http://www.google.com/adplanner/static/top1000/), so the potential fallout is large (even if users don't generally view the old download video reviews).

We also don't know if v.14 is older than v.2 (though likely), how many videos are using v1.4, if there are plans to update everything to v.2, if other Cnet properties are affected, if other players/sites may be affected by the same issue, etc.

Until we get more information we can not gauge the severity and impact of this bug (or the negative interaction between OOPP and certain videos) and thus cannot confidently conclude this is not a blocker.
Comment 17 mattburles 2010-06-04 15:03:17 PDT
so therefore it could be days or weeks before we find the cause of this problem and a potential fix?
Comment 18 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2010-06-04 15:12:27 PDT
I think the reasoning in comment 15 is pretty sound.  Why not release 3.6.4 with this bug and relnote it, giving users instructions for disabling OOPP if they run into this issue frequently?
Comment 19 mattburles 2010-06-04 15:14:45 PDT
(In reply to comment #18)
> I think the reasoning in comment 15 is pretty sound.  Why not release 3.6.4
> with this bug and relnote it, giving users instructions for disabling OOPP if
> they run into this issue frequently?

this sounds like a good idea to me they can just disable OOPP if they run into this problem until it is fixed in 3.6.5.
Comment 20 christian 2010-06-04 15:30:10 PDT
(In reply to comment #19)
> (In reply to comment #18)
> > I think the reasoning in comment 15 is pretty sound.  Why not release 3.6.4
> > with this bug and relnote it, giving users instructions for disabling OOPP if
> > they run into this issue frequently?
> 
> this sounds like a good idea to me they can just disable OOPP if they run into
> this problem until it is fixed in 3.6.5.

This is a non-starter. Most users a) don't read the release notes b) don't even know what OOPP is c) won't know how to use/will be scared by the warning in  about:config d) won't understand the problem more than "these videos used to work, now they don't for some reason, firefox sucks, it works in chome/ie/etc"

There is movement happening to answer the questions we need to make an informed decision. I believe the right people at Cnet are aware and can answer some questions. We have also opened a ticket with Adobe.
Comment 21 mattburles 2010-06-04 15:41:33 PDT
i guess its just a wait and see than although i would like to see 3.6.4 soon because OOPP has improved firefox a lot! :)
Comment 22 rsx11m 2010-06-04 17:41:54 PDT
Keep in mind that this is also delaying getting security fixes to the end user, not just for the 1.9.2 but also for the 1.9.1 branch (which has good builds up for a month now but being stalled by the OOPP feature backport for 3.6.4).

So, I'm wondering what's in the end more embarrassing: Not pushing important security updates to the users in a reasonable time, or a plug-in occasionally getting stuck on specific sites because of whatever interoperability issue?
Comment 23 chris hofmann 2010-06-04 18:36:33 PDT
(In reply to comment #9)
> I've been trying to diagnose this, it seems similar to bug 563361. There is a
> pre-roll advertisement video associated with this that seems to load, and then
> shutdown. Then the video loads up. Neither the ad, or the video play. Looking
> at the logs and stepping through a bit, I'm currently at a loss as to what
> might be the cause.

has anyone tried the test url on builds from the regression window mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=563361#c5 to see if we can confirm if this is related or not to that bug?
Comment 24 mattburles 2010-06-04 19:16:36 PDT
i am in agreement with comment #22
Comment 25 mattburles 2010-06-04 19:22:12 PDT
release 3.6.4 as is so users get the important security updates and fixes and when there is a fix for this bug than release 3.6.5
Comment 26 Jim Mathies [:jimm] 2010-06-05 09:11:01 PDT
(In reply to comment #22)
> Keep in mind that this is also delaying getting security fixes to the end user,
> not just for the 1.9.2 but also for the 1.9.1 branch (which has good builds up
> for a month now but being stalled by the OOPP feature backport for 3.6.4).
> 
> So, I'm wondering what's in the end more embarrassing: Not pushing important
> security updates to the users in a reasonable time, or a plug-in occasionally
> getting stuck on specific sites because of whatever interoperability issue?

I'm not sure why this is a concern. 3.6.3 is the current code base, if a critical security issue came up, we could easily clone 3.6.3, apply the fix, and release. 3.6.4 could then be bumped to 3.6.5. I doubt we are holding up major security fixes for this, but maybe the drivers could comment on that. We may be holding up various fixes that have been applied to 3.6.4pre along with OOPP, but that is pretty standard practice.
Comment 27 rsx11m 2010-06-05 09:19:27 PDT
Firefox 3.5.10 and SeaMonkey 2.0.5 builds have been up since May 4th, also Thunderbird 3.0.5 since May 12th. Neither is affected by the OOPP backport to the 1.9.2 branch but delayed anyway. I can't speculate which security issues may be solved by those updates as I'm not "in the loop" for those, but I'd tried to point out that good builds are unnecessarily delayed due to OOPP on
a different branch. This appears unreasonable, at least for the 1.9.1-branch builds, but the delay also raises eyebrows for the current release branch.
Comment 28 mattburles 2010-06-05 19:47:30 PDT
(In reply to comment #27)
> Firefox 3.5.10 and SeaMonkey 2.0.5 builds have been up since May 4th, also
> Thunderbird 3.0.5 since May 12th. Neither is affected by the OOPP backport to
> the 1.9.2 branch but delayed anyway. I can't speculate which security issues
> may be solved by those updates as I'm not "in the loop" for those, but I'd
> tried to point out that good builds are unnecessarily delayed due to OOPP on
> a different branch. This appears unreasonable, at least for the 1.9.1-branch
> builds, but the delay also raises eyebrows for the current release branch.

yeah delaying 3.6.4 more and more is gonna cause users to be sketchy on upgrading to the build because they will think the delays were a result of the software being too buggy and when it is released it will have the same result.
Comment 29 chris hofmann 2010-06-05 21:12:12 PDT
I'm away from my laptop most of this weekend, but here is a suggestion.  we should restrict comments in this bug to getting this bug fixed, and as soon as possible on the trunk and branches.

comments about when to ship 3.6.4, or not, or any other release should move to dev.planning or another forum.  

if someone could help out checking out comment 23 that would be great.
Comment 30 mattburles 2010-06-05 21:24:47 PDT
(In reply to comment #29)
> I'm away from my laptop most of this weekend, but here is a suggestion.  we
> should restrict comments in this bug to getting this bug fixed, and as soon as
> possible on the trunk and branches.
> 
> comments about when to ship 3.6.4, or not, or any other release should move to
> dev.planning or another forum.  
> 
> if someone could help out checking out comment 23 that would be great.

i would help you out but i dont know what URL i am supposed to be clicking on because it lists more than one and what i am looking for..
Comment 31 chris hofmann 2010-06-05 21:39:00 PDT
http://download.cnet.com/VLC-Media-Player/3000-13632_4-10267151.html?tag=mncol 

is the test case here I think.

Regression window for 1.9.3:

if video

Works:
http://hg.mozilla.org/mozilla-central/rev/600a41e39ab4
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100311
Minefield/3.7a3pre ID:20100311005442

and Fails:
http://hg.mozilla.org/mozilla-central/rev/dc3af645f713
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100311
Minefield/3.7a3pre ID:2010031109530

then it's highly likely this is the same as bug 563361 and one of the sites that could be affected by that bug.
Comment 32 mattburles 2010-06-05 21:59:22 PDT
yeah that video did fail for me when trying it on 3.6.4.. works fine on previous builds.
Comment 33 Alice0775 White 2010-06-05 22:04:23 PDT
(In reply to comment #31)
It seems to be different Regression window:

Works (IPC does not seems to be included in this build):
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091214 Minefield/3.7a1pre ID:20091214045914

Fails (set dom.ipc.plugins.enabled to true)
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091215 Minefield/3.7a1pre ID:20091215045531

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=44c392db6672&tochange=96e8d529b2d3
Comment 34 Frank Mar 2010-06-06 03:48:55 PDT
> 
> This is a non-starter. Most users a) don't read the release notes b) don't even
> know what OOPP is c) won't know how to use/will be scared by the warning in 
> about:config d) won't understand the problem more than "these videos used to
> work, now they don't for some reason, firefox sucks, it works in chome/ie/etc"
> 
> There is movement happening to answer the questions we need to make an informed
> decision. I believe the right people at Cnet are aware and can answer some
> questions. We have also opened a ticket with Adobe.

Sorry I cant be much more help... yeah Im a person who will say "it doesn't work, yet it works with chrome/ie/etc" - but I would never say Firefox sucks (cause I love it). I don't know much about this coding or w/e Im not that much of a techy. Im just the person who wants to politely tell of a bug, and so someone who does know can find a solution, or inform the people who can.
Comment 35 mattburles 2010-06-06 22:27:00 PDT
i emailed cnet to see what the problem is with these videos and this is what they told me..

Hello,

Thank you for bringing this to our attention. We have forwarded your inquiry to our CNET TV Team where they will investigate and resolve this matter internally. We appreciate your patience and apologize for any inconvenience it may have caused in the meantime.

Sincerely,

Pauline
CNET Customer Support



this makes me believe that it is not a firefox issue?
Comment 36 Michał Gołębiowski [:m_gol] 2010-06-07 00:04:21 PDT
@mattburles@live.com
>this makes me believe that it is not a firefox issue?

No, this only means You probably got an automated message and the final one may be sent in even a couple of weeks or more. There is no so much time before the release.

Anyway, Fx 3.6.4 gets delayed and delayed - if only OOPP is the cause of the issue, maybe it would be more reasonable to issue 3.6.4 without OOPP and 3.6.5 with it integrated in, like, a month?

Or at least announce build 7.
Comment 37 Mike Beltzner [:beltzner, not reading bugmail] 2010-06-07 08:41:38 PDT
All: as per comment 29, this bug is not the right place to advocate for when we ship Firefox 3.6.4, and whether or not we include OOPP in that release. I assure you that these issues are being discussed daily, and you can track that in the Delivery Meeting notes at http://wiki.mozilla.org/DeliveryMeetings

Alice: thanks for checking the regression ranges.

Matt: we're already in contact with CNet and Adobe, as per comment 20, but thanks for your efforts.

Please only add new information to this bug report, thanks, everyone!
Comment 38 Michał Gołębiowski [:m_gol] 2010-06-07 08:46:24 PDT
@Mike Beltzner
URL You provided seems not correct:
"There is currently no text in this page. You can search for this page title in other pages, search the related logs, or edit this page."
Comment 39 Mike Beltzner [:beltzner, not reading bugmail] 2010-06-07 08:49:00 PDT
Sorry - http://wiki.mozilla.org/Firefox/DeliveryMeetings
Comment 40 Michał Gołębiowski [:m_gol] 2010-06-07 12:04:13 PDT
(In reply to comment #33)
> Pushlog:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=44c392db6672&tochange=96e8d529b2d3

I narrowed it down a little (on Linux x86_64):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a732c6d3c078&tochange=cac067156b24

In 84b7c31ce666 it works, in cac067156b24 (with dom.ipc.plugins.enabled set to true) - it doesn't.

Builds from 999714b20f33 up to 05ac28100696 (probably a wider range, I didn't check all of them) hangs with dom.ipc.plugins.enabled set to true with an output:

[PluginModuleParent] LoadModule
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
---->   FAILED TO exec() CHILD PROCESS   <---
---->     path: /
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

** (firefox-bin:473): WARNING **: Serious fd usage error 17

** (firefox-bin:473): WARNING **: Serious fd usage error 14
Comment 41 mattburles 2010-06-08 12:11:31 PDT
what does this mean?
Comment 42 Michał Gołębiowski [:m_gol] 2010-06-22 13:35:45 PDT
I guess sb should remove the blocking flag for 1.9.2.4, as You issued Fx 3.6.4 a moment ago.
Comment 43 Michał Gołębiowski [:m_gol] 2010-06-24 18:08:48 PDT
Why is it written in release notes that this is an issue only under Windows? Linux suffers from this, too.
Comment 44 Cole Navarro 2010-07-30 11:01:58 PDT
the latest version of firefox 3.6.8 the flash player always crashed when a video start to load its works fine in youtube.com but the others site like http://veoh.com, http://onepieceofbleach.com and http://anime44.com its not loading its always flash player crash then i disable the crashed protection then try again if its works but firefox is not responding my flash player version is 10.1.53.64 
please fix problem
Comment 45 [not reading bugmail] 2010-07-30 11:32:15 PDT
(In reply to comment #44)
> the latest version of firefox 3.6.8 the flash player always crashed when a
> video start to load its works fine in youtube.com but the others site like
> http://veoh.com, http://onepieceofbleach.com and http://anime44.com its not
> loading its always flash player crash then i disable the crashed protection
> then try again if its works but firefox is not responding my flash player
> version is 10.1.53.64 
> please fix problem

Not related to this bug.  File a new bug please.
Comment 46 Hiram J. Perez 2010-12-11 12:06:41 PST
Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Currently working the old player videos with IPC plugins enabled
Comment 47 XtC4UaLL [:xtc4uall] 2011-02-13 07:38:27 PST
At least on the given example Url CNet now uses "CNET TV 3 Gecko v1.1c" as Player.

Given that, this is WFM on http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fc19169f304d Build http://hg.mozilla.org/mozilla-central/rev/51702867d932 using Flash 10.2.152.26.

=> Resolving WFM?
Comment 48 Alice0775 White 2011-02-13 07:44:52 PST
WFM2
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/ed0b2e310c16
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15pre) Gecko/20110213 Namoroka/3.6.15pre ID:20110213033206
http://hg.mozilla.org/mozilla-central/rev/51702867d932
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre ID:20110213030344
Comment 49 Paolo MARINI ♂ 2011-03-07 10:05:32 PST
I also have this problem and today I upgraded to 3.6.15 (as I was prompted to) but the issue still happens on both Windows XP and 7 and to be fair with also Chrome and Safari on the same two computers. Could it be something to do with the "thing" that cnetTV uses as these other two browsers still use the "Gecko TV 3" object?
Comment 50 RNicoletto 2011-03-10 01:54:13 PST
(In reply to comment #49)
> I also have this problem and today I upgraded to 3.6.15 (as I was prompted to)
> but the issue still happens on both Windows XP and 7...

This bug has been fixed on Firefox 4.0.x, not on Firefox 3.6.x.

Note You need to log in before you can comment on or make changes to this bug.