Closed Bug 300144 Opened 17 years ago Closed 14 years ago

mailnews.message_display.allow.plugins pref not followed

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bzbarsky, Unassigned)

References

Details

Suite has UI for the mailnews.message_display.allow.plugins pref, but the back
end never checks it (compare to nsMsgContentPolicy.cpp, which does).  This
should be fixed....
Actually, it's "followed" in that we don't create layout objects (but content
policy doesn't block them, so we may still load the data once biesi moves plugin
loading to content).  On branch this is a non-issue, but on trunk we want to fix
this, I think.
FWIW, the current version of my patch only loads plugins if a frame exists. but
yeah, the intent is to change that at some point.
So do we need to start using content policy?
It's a matter of what the "allow plugins" pref should mean.  Should it mean no
loading of the data?  Or should it mean no instantiating a plugin?
Flags: blocking-seamonkey2.0a1?
I would say this is fixed (or WFM) as Suite started using nsMsgContentPolicy.cpp back in 2006. Removing blocking request.
Flags: blocking-seamonkey2.0a1?
If we're using nsMsgContentPolicy, great.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.