Closed Bug 475299 Opened 15 years ago Closed 15 years ago

Windows media player content does not play or appear on


(Core Graveyard :: Plug-ins, defect, P2)



(Not tracked)



(Reporter: chadwickgab+mozilla, Assigned: jst)




(Keywords: fixed1.9.0.12, verified1.9.1)


(2 files, 2 obsolete files)

Windows media player does not play or appear on Just load this page with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090125 Minefield/3.2a1pre and no video plays. With Firefox 3.0.5 the video plays.

Video content should play.
Flags: blocking1.9.1?
This works in Firefox 3.1b2, so that narrows down the regression somewhat.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Assignee: nobody → jst
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1
I suppose i can confirm it this got the blocker status...
Ever confirmed: true
The problem here is that we end up instantiating the WMP plugin before the nsObjectFrame has been reflown, which leads us to call SetWindow on the plugin with a window height and widht of 0, which the plugin apparently can't deal with (even though we do pass it the right width and height later on).
Attached patch Fix. (obsolete) — Splinter Review
Boris, what do you think about this? We're instantiating plugins before they've been reflown, so they get a 0x0 sized window, and can't deal. This makes us force a reflow if that's about to happen, and that seems to fix this problem, w/o causing any other problems AFAICT.
Attachment #359439 - Flags: superreview?(bzbarsky)
Attachment #359439 - Flags: review?(bzbarsky)
Blocks: abp
Hmm.  This is probably ok, but shouldn't we ideally reget the frame after the flush instead of just bailing if it dies and a new one is created?
Attached patch Better fix. (obsolete) — Splinter Review
This re-fetches the frame, and bails if there is no frame to fetch.
Attachment #359439 - Attachment is obsolete: true
Attachment #359833 - Flags: superreview?(bzbarsky)
Attachment #359833 - Flags: review?(bzbarsky)
Attachment #359439 - Flags: superreview?(bzbarsky)
Attachment #359439 - Flags: review?(bzbarsky)
Comment on attachment 359833 [details] [diff] [review]
Better fix.

Why not just GetExistingFrame(eFlushLayout) if NS_FRAME_FIRST_REFLOW is set?  That'll flush and do a single hashtable lookup, basically...  And the code will be simpler.
Attached patch Better yet fix.Splinter Review
Yeah, this is cleaner for sure.
Attachment #359833 - Attachment is obsolete: true
Attachment #360205 - Flags: superreview?(bzbarsky)
Attachment #360205 - Flags: review?(bzbarsky)
Attachment #359833 - Flags: superreview?(bzbarsky)
Attachment #359833 - Flags: review?(bzbarsky)
Comment on attachment 360205 [details] [diff] [review]
Better yet fix.

Looks good.
Attachment #360205 - Flags: superreview?(bzbarsky)
Attachment #360205 - Flags: superreview+
Attachment #360205 - Flags: review?(bzbarsky)
Attachment #360205 - Flags: review+
Fixed on trunk and 1.9.1
Keywords: fixed1.9.1
Closed: 15 years ago
Resolution: --- → FIXED
Flags: in-litmus?
I get increasing reports of a very similar issue (by symptoms) in Firefox 3.0.6 - was the patch that caused this checked in there as well?
If this was caused by the object loading rewrite, then yes.  Years ago, in fact.
The original report claimed that the problem didn't occur in Firefox 3.0.5 - that's why I'm asking. I only started getting these issue reports recently.

Is there a chance that this can be fixed for 3.0 as well?
Hmm.  This bug claimed this to be a regression too.  Can we figure out from what? That might make it easier to figure out whether this is something we need to worry about on 1.9.0.
Unfortunately, I cannot reproduce the issue myself (though some users in my forum can). I checked and the first report of this issue was already in November, for Firefox 3.0.4. For reference, this is the forum thread:
I can verify that there is still a problem with the 3.0.x versions of Firefox.

Using this url:

I tested the following setup:

Firefox 3.0.6 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729) Ubiquity/0.1.5) using the Firefox Windows Media Player plugin.

The video gets obscured, but the audio is playing.  If you right click somewhere on the background of the page (Not in the media player section) and select "View Background Image" then while viewing that background image you right click (not on the image) and select "Back" the video player shows up.

I also tested this using the latest build of 3.0.7pre dated Feb 13 2009 and it still hasn't been fixed there.

I then tested using the latest mozilla1.9.1 nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090213 Shiretoko/3.1b3pre (.NET CLR 3.5.30729)) and everything works just fine.  (You have to set general.useragent.extra.firefox to Firefox/3.0.6 or something to get the player to work in Shiretoko)

So backporting this for Firefox 3.0.7 would really be nice as we have several customers who are being inconvenienced because of this regression/bug.
This still doesn't appear to be fixed completely in 3.0.10.


The page will load, the audio will be heard, but the video does not load in the designated frame.  If you navigate to another page and go back to the above, it will render properly.
Yeah, ok.  We should get this patch into 1.9.0.
Flags: blocking1.9.0.12?
Flags: blocking1.9.0.12? → wanted1.9.0.x+
Attachment #360205 - Flags: approval1.9.0.12+
Comment on attachment 360205 [details] [diff] [review]
Better yet fix.

Not blocking, but approved. If this is not the right patch please attach the correct one.

Approved for, a=dveditz for release-drivers
Checking in content/base/src/nsObjectLoadingContent.cpp;
/cvsroot/mozilla/content/base/src/nsObjectLoadingContent.cpp,v  <--  nsObjectLoadingContent.cpp
new revision: 1.99; previous revision: 1.98
I just checked this on Windows XP with 3.0.11 and last night's 1.9.0 build and I see no difference in behavior with any of the urls above.

With, video plays fine in both 3.0.11 and the build.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.