Closed Bug 563361 Opened 12 years ago Closed 12 years ago

[OOPP]Flash movie does not start at and maybe other sites that use <embed> tag


(Core Graveyard :: Plug-ins, defect)

1.9.2 Branch
Windows 7
Not set


(blocking1.9.2 needed, status1.9.2 .9-fixed)

Tracking Status
blocking1.9.2 --- needed
status1.9.2 --- .9-fixed


(Reporter: alice0775, Assigned: benjamin)




(Keywords: regression, testcase, Whiteboard: [oopp-watchlist])


(6 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100503 Namoroka/3.6.5pre ID:20100503042704
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100503 Namoroka/3.6.5pre ID:20100503042704

Flash movie would not start on

If I disabled dom.ipc.plugins.enabled.npswf32.dll, then the movie will start.

Reproducible: Always

Steps to Reproduce:
1. Start Namoroka with "NEW profile".
2. Go URL ( )

Actual Results:
 Flash  movie does not start

Expected Results:
 Flash movie should start
Severity: blocker → major
Component: Plug-ins → IPC
QA Contact: plugins → ipc
Is there a movie at this site all the time, or just during games? I tried this both OOPP and IPP with mozilla-central:

IPP: main area is black (flash active)
OOPP: main area shows a static picture of a futbol player, (flash active)
Component: IPC → Plug-ins
QA Contact: ipc → plugins
Not all the time.
but it should not be black.
Not yet fixed the bug on Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100522 Namoroka/3.6.5pre ID:20100522042222
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100415 Namoroka/3.6.5pre
Able to reproduce. If I disabled dom.ipc.plugins.enabled.npswf32.dll, then the flash content plays.
Regression window for 1.9.3:

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100311 Minefield/3.7a3pre ID:20100311005442

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100311 Minefield/3.7a3pre ID:20100311095301

Keywords: regression
I confirmed in local build.
Reverted to 6d13458be1b0, the problem was gone.
Blocks: 551049
Is this regression blocking 3.6.5?
Regression for 1.9.2 : 

Build worked :  
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100318 Namoroka/3.6.3pre

Build broken :  
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100323 Namoroka/3.6.3pre
Lorentz builds are missing in between, only namoroka builds are present.
So. Bug 548217 causes this problem in 1.9.2 branch.
and Bug 551049  causes this problem in 1.9.3 trunk.
This bug is not currently nominated to block any release, and at this point I don't think it blocks any release at least until somebody can get it in recording. I've never gotten that site to do anything useful from the US.
Attached file testcase
1.Extracted a zip file
2.Open Bug563361testcase.html

if Enabled OOPP, a black rectangle is displayed only .

An image should be displayed.
Keywords: testcase
Benjamin, does this testcase help to get a better understanding of that problem and if we have to block on it?
blocking1.9.2: --- → ?
status2.0: --- → ?
Alice, did you write the .swf file, or is it something you pulled off the site?
It come from
Attached file testcase2
If I use object tag instead of embed tag, it worked with OOPP.

Upper ; embed tag which is used in a site
Lower : object tag.
Confirmed with:
- Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv: Gecko/20100527
- Adobe Flash Player 10,1,53,60 (10.1rc6)
- Gainward GeForce GT 240 Golden Sample
- nVIDIA ForceWare 197.44 (

testcase = black
testcase2 = logo
IPP, the plugin makes a call to NPN_GetURLNotify:

>	xul.dll!mozilla::plugins::parent::_geturlnotify(npp=0x081b738c, relativeURL=0x0b4d0770, target=0x00000000, notifyData=0x00000002)  Line 934	C++
 	xul.dll!nsBaseAppShell::OnProcessNextEvent(thr=0x72790bdf, mayWait=0x007b9784, recursionDepth=0x0071fab0)  Line 294	C++

OOPP, this call is never made. (The URL is images/flash/1.jpg, but I don't really think it matters).

The message is WM_USER + 1.
This is a verbose log of the failing <embed> OOPP
This is a verbose log of <object> succeeding OOPP. Oddly, we appear to be sending the .swf file to the plugin twice.
A log of the <embed> testcase being run IPP. We only deliver the data once, but the plugin seems to start doing it's real work correctly.

I verified in recording that we appear to be delivering the SWF stream data correctly and calling NPP_DestroyStream with NPRES_DONE.
We don't have enough information to block on this bug but I am a bit worried it will blow up when we ship. Embed is likely more common than object, and I'm worried there is something about the video or embed here that is fairly common around the web. That being said, we can't block on worries without supporting information.
blocking1.9.2: ? → .5+
bc's spider might be able to tell us about places where the object tag is not working due this bug, and other places where it might be working ok.
(In reply to comment #22)
> bc's spider might be able to tell us about places where the object tag is not
> working due this bug, and other places where it might be working ok.

er, places where the embed tag is working, or not...
How would the spider know? It's not like there's any crashing here, it either displays a video or a black background.
IIRC, the spider can be set to scan and watch for a given tag or content pattern. 

Once we have that list we have the ability to have a look at what might be going on across a number of pages and sites that match the pattern.  

We have used this kind of thing in the past to look for places where JS changes might have resulted in compatibility problems.

looks like bc isn't on-line today but when he gets back maybe he can take a look.
I'm trying to see what signature I can discover that will allow detection of the issue. I'll comment on my results later today.
any updates on this issue?!
I can unreliably detect the issue by:

a) if the plugin never initializes to the point where calling plugin.PercentLoaded() does not throw a "NPMethod called on non-NPObject wrapped JSObject!" error. This works sometimes on 1.9.3 linux.

a) if plugin.Play() on a non-playing swf still results in plugin.IsPlaying() returning false. This works sometimes on 1.9.2, 1.9.3 windows xp.

Do those results make sense in the context of what else is known about this bug?
bsmedberg would have to speak to that. By "works sometimes" do you mean the test actually passes sometimes for those versions when you expect it to error out consistently? Or do you mean the test sometimes catches the wrong behavior but generally does not?
The symptoms of this particular bug are that it never requests any files using NPN_GetURLNotify. I don't know anything about how that might translate into PercentLoaded or Play calls.
Oops. I reordered the items but left the labels... doh. the second should have been b of course.

By "works sometimes", I meant that the error in a) or the failure to play in b) would occur sometimes for the embed tests in testcase attachment 448152 [details] and testcase2 attachment 448519 [details] but never in 1.9.1 on either embed or object and never in 1.9.2/1.9.3 on the object.

If the flash file isn't loaded, then we should expect an error trying to call methods on it. I'm not entirely sure what the significance of the failure to play means.
It is hard for me to tell for certain, but can anyone else tell if these urls exhibit the problem? They all failed to initialize and repeatedly resulted in Error: NPMethod called on non-NPObject wrapped JSObject! attempting to get PercentLoaded().

There were tested using Flash 10.1 rc7. There were originally from a list of urls which crashed Flash. YMMV. This list is just the beginning of testing several hundred previously crashing flash urls. If these meet the criteria there are probably plenty more.
At I get an actionscript error using flash player debug version:

TypeError: Error #1009: Cannot access a property or method of a null object reference.
	at tv.ustream.components.gui::Button/set label()
	at tv.ustream.components.gui::ComboBox/set label()
	at panels::CohostSettingsPanel/onAddedToStage()
	at flash.display::DisplayObjectContainer/addChild()
	at ViewerDocument/createViewerClass()
	at ViewerLocaleInit/onLocaleComplete()
	at tv.ustream.localization::Locale/onAmfResult()

But I'm not sure it's related to this bug at all, and I'm not which flash instance it's coming from.

I don't see any errors on or the other sites you've listed.
benjamin, ok. I'll consider the signature to be a failure and won't add more urls unless you think it would be useful. /me over and out.
Thanks for trying bc.
blocking1.9.2: .5+ → .6+
Whiteboard: [oopp-watchlist]
We have a clue about what's going wrong.  It has to do with the flashvars coming in from the tag:


The SWF has this code in it:

    if (((photoID != undefined) && (movieID != undefined)) && ((photoID > 0) && (movieID > 0))) {
        gotoAndStop (2);
    } else {
        errorLogo_mc._visible = true;

From debugging the player I know that the flashvars *are* coming in.  I suspect they're coming in at the wrong time.  I'll keep digging, but does this give you any ideas on your side?
We'll take a look, thanks Jeff!
Summary: [OOPP]Flash movie does not start at certain site → [OOPP]Flash movie does not start at and maybe other sites that use <embed> tag
Assignee: nobody → benjamin
As far as I know, all the variables come in the call to NPP_New, and I verified pretty early on that they are correct. Are you saying that the code in question is running *before* NPP_New is called? Or that the argc/argn/argv being passed to NPP_New aren't making it to the Flash app in the normal manner?
Yes, all the variables come in on NPP_New.  That if statement may be a red herring - I'm digging deeper into the player trying to figure out exactly what's going wrong.
blocking1.9.2: .6+ → needed
A little bit of Flash Player internals here.  The movie has multiple frames, where each frame is distinct context in which ActionScript can run. The first frame has just a little bit of code which looks at the flashvars, and if it likes them it tries to jump over to the second frame and play the content.

What's happening is, apparently, the second frame isn't there yet.  We're wondering if maybe the player is getting a smaller buffer of network data to work with?  If we haven't got all the data for frame two we can't create it.

I'll be trying to answer all these questions in the debugger when I get a chance, but that might be a while, so I wanted to throw the idea out there in case it made sense from your side.
Yes, we are chunking network data into buffers no larger than 0x1000 large. We need a limit so that we don't end up blocking the IPC pipe between processes, but I chose this number rather arbitrarily. Is there another size which might help alleviate this type of problem?
Attachment #455502 - Flags: review?(bent.mozilla)
Oh, and I've verified that the testcase works with this change.
Great news, but we may need to do some player work to make sure no other poorly written sites out there can break.  Is there any way to estimate how big the first chunk of data tended to be with the in process browser?
I'm certain we don't have that data currently, or any easy way to collect it.
Attachment #455502 - Flags: review?(bent.mozilla) → review+
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 455502 [details] [diff] [review]
Increase chunk size, rev. 1

Very low risk.
Attachment #455502 - Flags: approval1.9.2.8?
Attachment #455502 - Flags: approval1.9.2.7?
Comment on attachment 455502 [details] [diff] [review]
Increase chunk size, rev. 1

a=LegNeato for Please land this on mozilla-1.9.2 default.
Attachment #455502 - Flags: approval1.9.2.8?
Attachment #455502 - Flags: approval1.9.2.8+
Attachment #455502 - Flags: approval1.9.2.7?
Attachment #455502 - Flags: approval1.9.2.7-
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.