Closed Bug 391261 Opened 17 years ago Closed 17 years ago

No windows media player invoked anymore with this testcase

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: Biesinger)

References

Details

(Keywords: regression, testcase)

Attachments

(4 files, 2 obsolete files)

Attached file testcase (deleted) —
See testcase, normally I get to see the windows media player invoked with it, showing a short movie. But in current trunk build, this doesn't work anymore. It worked in yesterday's trunk build. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-08-06+04&maxdate=2007-08-07+09&cvsroot=%2Fcvsroot Regression from bug 364235 or perhaps more likely, bug 390385.
Flags: blocking1.9?
Version: 1.8 Branch → Trunk
OK, can you give some more details, like OS, version of WMP, version of the plugin? this does work for me on winxp with WMP 11.
I'm using WMP 10 on windowsXP.
do you have a debug build? if so, could you make a log with NSPR_LOG_MODULES=objlc:5,Plugin:5,PluginNPP:5,PluginNPN:5
Assignee: nobody → cbiesinger
Attached file nsprlog (obsolete) (deleted) —
Sorry, my debug build is too old for this 1 day old regression. It seems like regular builds also give (useful?) data with this option. Maybe this is what you need?
Attached file nsprlog (obsolete) (deleted) —
Sorry, I attached the wrong kind of log, this one is with the correct settings, with: set NSPR_LOG_MODULES=objlc:5,Plugin:5,PluginNPP:5,PluginNPN:5
Attachment #275673 - Attachment is obsolete: true
Attached file nsprlog (deleted) —
Ok, this is now an nsprlog from my updated debug build.
Attachment #275806 - Attachment is obsolete: true
this looks ok.... but the warning near the end looks suspicious. Could you try applying the patch in bug 381812 and see whether that helps?
I applied the patch from bug 381812 and rebuilt my tree, and I can still see this bug afterwards.
Attached patch experimental patch (deleted) — Splinter Review
Martijn, could you see if this patch fixes the issue? (it's a hack... not for checkin, just for experimenting)
Yes, that experimental patch fixes the issue for me.
Attached patch patch (deleted) — Splinter Review
Attachment #277129 - Flags: superreview?(bzbarsky)
Attachment #277129 - Flags: review?(bzbarsky)
So why does this work? Document on the second CallSetWindow why it's needed?
like this? // WMP10 needs an additional SetWindow call here (bug 391261) I don't know exactly why it's needed, but apparently it is...
Comment on attachment 277129 [details] [diff] [review] patch If that's the best we can do, then yes... :(
Attachment #277129 - Flags: superreview?(bzbarsky)
Attachment #277129 - Flags: superreview+
Attachment #277129 - Flags: review?(bzbarsky)
Attachment #277129 - Flags: review+
Attachment #277129 - Flags: approval1.9+
Checking in nsObjectFrame.cpp; /cvsroot/mozilla/layout/generic/nsObjectFrame.cpp,v <-- nsObjectFrame.cpp new revision: 1.613; previous revision: 1.612 done Checking in nsObjectFrame.h; /cvsroot/mozilla/layout/generic/nsObjectFrame.h,v <-- nsObjectFrame.h new revision: 1.70; previous revision: 1.69 done
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Thanks, it's working fine now, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082111 Minefield/3.0a8pre
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: