Closed
Bug 309523
Opened 19 years ago
Closed 17 years ago
Sort out whether plugins should be instantiatable via file extensions
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: Biesinger, Assigned: Biesinger)
References
Details
Attachments
(1 file)
899 bytes,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
bug 1156 added this XXX comment in nsObjectLoadingContent.cpp:
>+ // XXX do plugins expect to work via extension too?
This needs to be sorted out one way or another (ideally by just removing that
comment)
Comment 1•19 years ago
|
||
So I was thinking.... If there is a type attribute, people really have no
excuse for wanting the extension. So the only thing that matters is the "no
type attribute" case.
In this case, we go out to the network, right? And things like file:// will
already use extensions... So the only question is HTTP and such....
If I read the old code correctly, we just passed stuff in to
nsPluginHostImpl::SetUpPluginInstance, right? And that does:
3850 // if don't have a mimetype or no plugin can handle this mimetype
3851 // check by file extension
3852 if(!aMimeType || NS_FAILED(IsPluginEnabledForType(aMimeType))) {
...
3862 NS_FAILED(IsPluginEnabledForExtension(fileExtension.get(),
3863 mimetype))) {
Assignee | ||
Updated•19 years ago
|
Summary: Sort out whether plugins should be instantiatable via extensions → Sort out whether plugins should be instantiatable via file extensions
Flags: blocking1.9? → blocking1.9-
Comment 3•18 years ago
|
||
I think this should be at least wanted. We need to sit down and figure out whether this causes regressions for popular plugins/sites.
That is, making the code change is not a blocker. Deciding whether we need to make the code change should be.
Renominating.
Flags: blocking1.9- → blocking1.9?
Fair enough
Flags: blocking1.9? → blocking1.9+
Assignee | ||
Comment 6•17 years ago
|
||
That's checked in now; it made plugins instantiatable by extensions for <embed> but not for <object>. I think that should be fine.
Assignee | ||
Comment 7•17 years ago
|
||
Attachment #272864 -
Flags: superreview?(bzbarsky)
Attachment #272864 -
Flags: review?(bzbarsky)
Updated•17 years ago
|
Attachment #272864 -
Flags: superreview?(bzbarsky)
Attachment #272864 -
Flags: superreview+
Attachment #272864 -
Flags: review?(bzbarsky)
Attachment #272864 -
Flags: review+
Assignee | ||
Comment 8•17 years ago
|
||
Checking in nsObjectLoadingContent.cpp;
/cvsroot/mozilla/content/base/src/nsObjectLoadingContent.cpp,v <-- nsObjectLoadingContent.cpp
new revision: 1.49; previous revision: 1.48
done
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•