Closed
Bug 539964
Opened 15 years ago
Closed 9 years ago
OOPP A movie is played intermittently when the mouse pointer is staying over video control.
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: alice0775, Unassigned)
References
()
Details
Attachments
(2 files)
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
![]() |
Reporter | |
Updated•15 years ago
|
Version: unspecified → Trunk
![]() |
Reporter | |
Updated•15 years ago
|
Summary: OOPP An movie is played intermittently when the mouse pointer is staying over video control. → OOPP A movie is played intermittently when the mouse pointer is staying over video control.
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.
Was there any NS_WARN_IF_FALSE output before the problem starts indicating a Reflow method might have failed?
Comment 3•15 years ago
|
||
Here's a log of debug spew. The RPCChannel payload error is concerning too.
I don't see anything in that log indicating reflow failure.
I seen this with videos on yahoo a few times yesterday
Status: UNCONFIRMED → NEW
Ever confirmed: true
Filed bug 540089 on the payload errors. Pretty innocuous bug atm, nothing to worry about.
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?
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.
Comment 11•15 years ago
|
||
The problem I'm seeing on youtube was on Linux, actually, so maybe that's a different bug?
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. :)
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).
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.
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.
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.
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.
![]() |
||
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.
Assignee: nobody → jmathies
![]() |
||
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.
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.
![]() |
||
Updated•15 years ago
|
Assignee: jmathies → nobody
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 ?
(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.
![]() |
Reporter | |
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Status: REOPENED → NEW
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.
![]() |
Reporter | |
Comment 25•9 years ago
|
||
no longer available the page
Status: NEW → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → INCOMPLETE
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•