Closed Bug 78009 Opened 24 years ago Closed 24 years ago

[RFE] Include Shockwave DLL (np32dsw.dll) in 4.x plugin scan

Categories

(Core Graveyard :: Plug-ins, enhancement, P3)

x86
Windows 2000
enhancement

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9

People

(Reporter: peterlubczynski-bugs, Assigned: peterlubczynski-bugs)

References

()

Details

(Whiteboard: [seeking review])

Since Shockwave support has gotten better, it would probably now be desireable to include Shockwave in our 4.x plugin path scan.
This patch in nsPluignHostImpl.cpp should do the job: static PRBool isUnwantedPlugin(nsPluginTag * tag) { if(tag->mFileName == nsnull) return PR_TRUE; for (PRInt32 i = 0; i < tag->mVariants; ++i) { if(nsnull == PL_strcasecmp(tag->mMimeTypeArray[i], "audio/x-pn-realaudio-plugin")) return PR_FALSE; if(nsnull == PL_strcasecmp(tag->mMimeTypeArray[i], "application/pdf")) return PR_FALSE; if(nsnull == PL_strcasecmp(tag->mMimeTypeArray[i], "application/x-shockwave-flash")) return PR_FALSE; + if(nsnull == PL_strcasecmp(tag->mMimeTypeArray[i],"application/x-director")) + return PR_FALSE; } return PR_TRUE; }
Wow, that's a weird function. A negative name (_un_wanted) and it returns false on a match.
Negative logic is no worse than positive one. Just a matter of habit. In this particular case this is somewhat natural. If you look at the scheme of scanning plugins you'll notice that it fits in the logic of the bigger process: first we find next plugin, assume that we should to add it to the list and then start to check different reasons why we may want _not_ to include it before we make a final decision. Being _un_wanted (when scanning 4.x installation) is just one of those reasons.
Phil, per the Friday plugin meeting, do you want this to go in? How about mozilla0.9?
av: makes sense in the total scope, I guess. Didn't read that far. I wasn't knocking anything, either, just poking my nose where it doesn't belong (!).
Oh, I did not mean anything. Everybody's nose is warmly welcome :)
> Phil, per the Friday plugin meeting, do you want this to go in? How about > mozilla0.9? Definitely on the trunk. If it's still true that Shockwave won't install into a mozilla-based browser, then we should do it on the branch too.
Okay, so Andrei I r= your patch. I guess Phil implies an a=, if needed. Marc, can I get an sr= and then I'll check it into the BRANCH. I'll see if drivers@mozilla.org will allow this for mozilla0.9 then.
Severity: normal → enhancement
Status: NEW → ASSIGNED
Keywords: patch
Priority: -- → P3
Summary: Include Shockwave DLL (np32dsw.dll) in 4.x plugin scan → [RFE] Include Shockwave DLL (np32dsw.dll) in 4.x plugin scan
Whiteboard: [seeking review]
Target Milestone: --- → mozilla0.9.1
I cannot approve it, but I will give my sr=attinasi (ask drivers for a=)
Patch checked into the TRUNK: /cvsroot/mozilla/modules/plugin/nglsrc/nsPluginHostImpl.cpp,v <-- nsPluginHostImpl.cpp new revision: 1.241; previous revision: 1.240
a=chofmann for the 0.9 branch if you can get it in quickly..
quick enough? -->mid air collision :) Patch checked into the BRANCH. Marking FIXED. /cvsroot/mozilla/modules/plugin/nglsrc/nsPluginHostImpl.cpp,v <-- nsPluginHostImpl.cpp new revision: 1.233.4.4; previous revision: 1.233.4.3
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: mozilla0.9.1 → mozilla0.9
filed bug 78751 for this same issue on MAC.
verified on the trunk, now the 4.x shockwave plugin is getting picked up in the scan. doing 'about:plugins' lists the4.x shockwave plugin. marking VERIF.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.