Alice0775 White Reporter
	Description • 15 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2pre) Gecko/20100115 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100115 Minefield/3.7a1pre ID:20100115055022

Enable dom.ipc.plugins.enabled to true,

A movie is played intermittently when the mouse pointer is staying over video control.
However sound is not played intermittently.

A movie is continued when I move mouse pointer.


Reproducible: Always

Steps to Reproduce:
1.Start Minefield with FlashPlayer 10.0.42.34 and dom.ipc.plugins.enabled to true,
2.Go URL ( http://www.adobe.com/products/flashplayer/features/ )
3.Expand "FEATURES"by clicking in the right side of the Flash.
4.Choose "Hardware acceleration"
5.Click "Video" at the right-bottom of the Flash
6. Stay mouse pointor over video contorol

Actual Results:  
A movie is played intermittently.
However sound is not played intermittently.

Expected Results:  
A movie should not be played intermittently.


This issue only happens when you set dom.ipc.plugins.enabled to true,

My PC: C2Q 2.5GHz, MEM8GB, ATI Radeon HD4350

	Benjamin Smedberg
	Comment 1 • 15 years ago

From my current testing, the plugin process is running, but the browser process is semi-stuck... I get a bunch of assertions in a loop:

###!!! ASSERTION: cannot call GetUsedBorder on a dirty frame not currently being reflowed: 'nsLayoutUtils::sDisableGetUsedXAssertions || !NS_SUBTREE_DIRTY(this) || (GetStateBits() & NS_FRAME_IN_REFLOW)', file c:/builds/electrolysis/ff-debug/layout/generic/../../../src/layout/generic/nsFrame.cpp, line 591

I'm not sure exactly why this stops the video from drawing, but when the assertions finally stop the video does draw. This may be focus-related.

	David Baron :dbaron:
	Comment 2 • 15 years ago

Was there any NS_WARN_IF_FALSE output before the problem starts indicating a Reflow method might have failed?

	Benjamin Smedberg
	Comment 3 • 15 years ago

Here's a log of debug spew. The RPCChannel payload error is concerning too.

	David Baron :dbaron:
	Comment 4 • 15 years ago

I don't see anything in that log indicating reflow failure.

	u88484
	Comment 5 • 15 years ago

I seen this with videos on yahoo a few times yesterday

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
	Comment 6 • 15 years ago

Filed bug 540089 on the payload errors.  Pretty innocuous bug atm, nothing to worry about.

	IU
	Comment 8 • 15 years ago

I wonder if this is the bug I'm running into.  Playing video served by certain types of embedded flash players (the type that prevents caching of video, so they cannot be downloaded: e.g. players at cbsnews.com, watch.ctv.ca, globaltv.com), after a while all video update stops but audio continues, and the whole browser interface becomes unresponsive.  Moving the mouse does nothing.  My only recourse is to kill mozilla-runtime.exe, thus unfreezing the browser and allowing me to reload the page and restart the video)

Maybe I'm experiencing a different problem and need to file a new bug?

	IU
	Comment 9 • 15 years ago

Here's one such video where I'm getting the locking up: http://www.cbsnews.com/video/watch/?id=6135088n

After you start the video, leave it to play until the video stops updating and all you get is audio.

	Johnny Stenback (:jst)
	Comment 10 • 15 years ago

FWIW, this seems to be happening on youtube videos as well.

	Johnny Stenback (:jst)
	Comment 11 • 15 years ago

The problem I'm seeing on youtube was on Linux, actually, so maybe that's a different bug?

	Justin Lebar (not reading bugmail)
	Comment 12 • 15 years ago

It happens to me on Windows on Hulu, even when I don't leave the mouse cursor over the video.  Haven't seen this particular bug yet on Youtube, although there's plenty of instability to be had.  :)

	Benjamin Smedberg
	Comment 13 • 15 years ago

Youtube is windowed and hulu is windowless, and therefore they are likely to be different bugs (but I'm not certain about that).

	Ben Turner (not reading bugmail, use the needinfo flag!)
	Comment 14 • 15 years ago

I can't reproduce this on either of the URLs in this bug. Ted mentioned that Flashblock may be playing a role as he became unable to reproduce with it disabled. I installed Flashblock to test but still can't reproduce.

	Justin Lebar (not reading bugmail)
	Comment 15 • 15 years ago

fwiw I'm not running flashblock and reproduced the hang on the video at http://www.adobe.com/products/flashplayer/features/

The first time I did it I left my mouse over the video and it hung about halfway through.  The second time, I didn't leave my mouse over the video and it hung about 5/6 of the way through.

Feb 3 trunk build on Windows XP.

	Tyler Downer [He/Him]
	Comment 16 • 15 years ago

Alright, so, a link that shows this reliably are the foxnews videos. For example, http://video.foxnews.com/v/4001051/politics-over-protection. Mouse over video, video stops after a few seconds, then stops. Sound continues. However, sometimes, when moving the mouse off of the content, the video will still stop. Not always, but on occasion.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100203 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20100203081257 with dom.ipc.plugins.enabled true. I also see justin's issue.

	(not currently active) Ted Mielczarek
	Comment 17 • 15 years ago

I can reproduce this with Tyler's fox news URL on Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100204 Minefield/3.7a1pre.

I find that it's reproducible as long as you don't move the mouse over the browser window *at all*. Just let the video play and don't move the mouse at all, and the video will stop playing after a while (10 seconds in my last test). Moving the mouse over the browser window makes it start again.

	Jim Mathies [:jimm]
	Comment 18 • 15 years ago

Sounds like a WaitForNotify hold-up problem where we somehow call MsgWaitForMultipleObjects after the thread message is posted. I've seen this in race testing in bug 538918. I'd like to look at this after I'm done with that patch.

	Jim Mathies [:jimm]
	Comment 19 • 15 years ago

(In reply to comment #18)
> Sounds like a WaitForNotify hold-up problem where we somehow call
> MsgWaitForMultipleObjects after the thread message is posted. I've seen this in
> race testing in bug 538918. I'd like to look at this after I'm done with that
> patch.

^^ This would be for windowless only though, not windowed.

	(not currently active) Ted Mielczarek
	Comment 20 • 15 years ago

Stacks from parent and child when this happens. Hope that helps.

	Ben Turner (not reading bugmail, use the needinfo flag!)
	Comment 21 • 15 years ago

Ok, finally managed to reproduce this and get it in a debugger. Parent is in the WaitForNotify loop after sending some message (NPP_SetWindow in this case). Child calls back to the parent (CallNPN_GetValue_NPNVnetscapeWindow in this case), and somehow that doesn't trigger the parent to leave the WaitForNotify loop. The message is received (mPending has one message in it) but apparently we never sent the "wake up" message. Badness.

	Ria Klaassen (not reading all bugmail)
	Comment 22 • 15 years ago

(In reply to comment #11)
> The problem I'm seeing on youtube was on Linux, actually, so maybe that's a
> different bug?

Is this Linux bug a duplicate: Bug 544882 ?

	David Baron :dbaron:
	Comment 23 • 15 years ago

(In reply to comment #1)
> From my current testing, the plugin process is running, but the browser process
> is semi-stuck... I get a bunch of assertions in a loop:
> 
> ###!!! ASSERTION: cannot call GetUsedBorder on a dirty frame not currently
> being reflowed: 'nsLayoutUtils::sDisableGetUsedXAssertions ||
> !NS_SUBTREE_DIRTY(this) || (GetStateBits() & NS_FRAME_IN_REFLOW)', file
> c:/builds/electrolysis/ff-debug/layout/generic/../../../src/layout/generic/nsFrame.cpp,
> line 591
> 
> I'm not sure exactly why this stops the video from drawing, but when the
> assertions finally stop the video does draw. This may be focus-related.

Bug 542361 should make these assertions go away; not sure if it will make the loop go away.

	(No longer employed by Mozilla) Aaron Klotz
	Comment 24 • 9 years ago

(In reply to Ben Turner [:bent] (use the needinfo flag!) from comment #21)
> Ok, finally managed to reproduce this and get it in a debugger. Parent is in
> the WaitForNotify loop after sending some message (NPP_SetWindow in this
> case). Child calls back to the parent (CallNPN_GetValue_NPNVnetscapeWindow
> in this case), and somehow that doesn't trigger the parent to leave the
> WaitForNotify loop. The message is received (mPending has one message in it)
> but apparently we never sent the "wake up" message. Badness.

This looks to me like an instance of bug 1170231.

	Alice0775 White Reporter
	Comment 25 • 8 years ago

no longer available the page