Last Comment Bug 309524 - Call ShouldProcess in all cases for <object>
: Call ShouldProcess in all cases for <object>
[sg:want P5]
: sec-want
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
-- normal with 4 votes (vote)
: mozilla17
Assigned To: John Schoenick [:johns]
: Andrew Overholt [:overholt]
Depends on: 781126
Blocks: 1156
  Show dependency treegraph
Reported: 2005-09-21 13:26 PDT by Christian :Biesinger (don't email me, ping me on IRC)
Modified: 2012-08-29 11:23 PDT (History)
13 users (show)
reed: wanted1.9+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Christian :Biesinger (don't email me, ping me on IRC) 2005-09-21 13:26:26 PDT
<object> (and <embed>, <applet>) should call nsIContentPolicy::ShouldProcess.
needs sorting out whether it should call that itself or whether
LoadImageWithChannel etc should do that.
Comment 1 User image Jesse Ruderman 2006-12-16 15:02:30 PST
This is needed in order for NoScript to soundly block particular plugins, isn't it?  The mime type guess passed to ShouldLoad could be application/x-shockwave-flash for something that isn't ultimately treated as Flash, and vice versa.
Comment 2 User image Jesse Ruderman 2006-12-17 06:10:58 PST
NoScript contains a hack to work around the lack of a shouldProcess call:

<mao> I use a webprogress listener and brutally block the loading in particular circumnstances (i.e. when shouldLoad() and shouldProcess() may be fooled)

It would be better if NoScript didn't need that hack, of course.
Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2007-08-23 22:28:11 PDT
Note that I'm adding such a call in bug 393503.  It doesn't get called for all the various plugin cases, however....
Comment 4 User image obsolete.fax 2010-05-19 10:22:49 PDT
add to Keywords: privacy
Comment 5 User image shawn.sumin 2011-03-31 16:05:51 PDT
The Tor Project / Electronic Frontier Foundation is paying to have this bug

"If you know C++ and/or Firefox internals, we should be able to pay you for
your time to address these issues and shepherd the relevant patches through
Mozilla's review process."

Comment 6 User image Johnathan Nightingale [:johnath] 2011-05-12 14:31:44 PDT
Clearing the noms - old bug nominated for tracking without justification. Please be careful with flags.
Comment 7 User image John Schoenick [:johns] 2012-08-10 17:09:11 PDT
bug 781126 should fix this

After that lands the behavior is
1) [if using channel] Call shouldLoad() with the best-guess type prior to opening channel
2) Call shouldLoad() again with final type
3) Call shouldProcess() with final type

#2 wouldn't be necessary except for bug 380556
Comment 8 User image John Schoenick [:johns] 2012-08-10 17:21:20 PDT
Actually I lied. The behavior is

1) [if using channel] Call shouldLoad() up to three times with all possibly-supported types (document/image/object) to see if there's any type that would be allowed from the channel
2) Call shouldLoad again with final type
3) Call shouldProcess with final type

Additionally, for plugins without URIs, we call shouldLoad() and shouldProcess() using the document's URI and TYPE_OBJECT

#1 Might be simplified by using TYPE_REFRESH or something similar, but that is not fully implemented
#2 wouldn't be necessary except for bug 380556

However, overall, it should be much simpler for implementers of content policy to handle this - just returning the right thing in shouldLoad() and shouldProcess() should work as expected
Comment 9 User image John Schoenick [:johns] 2012-08-29 11:23:30 PDT
Bug 781126 ended up landing with a much more proper fix, so ignore the above comments.

- We call shouldLoad(TYPE_OBJECT) before opening a channel
- We call shouldProcess(ACTUAL_TYPE) before instantiating a plugin/image/subdocument. If there is no channel, only shouldProcess gets called.

Note You need to log in before you can comment on or make changes to this bug.