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)
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;
}
Comment 2•24 years ago
|
||
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.
Assignee | ||
Comment 4•24 years ago
|
||
Phil, per the Friday plugin meeting, do you want this to go in? How about
mozilla0.9?
Comment 5•24 years ago
|
||
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 :)
Comment 7•24 years ago
|
||
> 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.
Assignee | ||
Comment 8•24 years ago
|
||
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
Comment 9•24 years ago
|
||
I cannot approve it, but I will give my sr=attinasi (ask drivers for a=)
Assignee | ||
Comment 10•24 years ago
|
||
Patch checked into the TRUNK:
/cvsroot/mozilla/modules/plugin/nglsrc/nsPluginHostImpl.cpp,v <--
nsPluginHostImpl.cpp
new revision: 1.241; previous revision: 1.240
Comment 11•24 years ago
|
||
a=chofmann for the 0.9 branch if you can get it in quickly..
Assignee | ||
Comment 12•24 years ago
|
||
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
Comment 13•24 years ago
|
||
filed bug 78751 for this same issue on MAC.
Comment 14•24 years ago
|
||
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
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
•