<object> (and <embed>, <applet>) should call nsIContentPolicy::ShouldProcess. needs sorting out whether it should call that itself or whether LoadImageWithChannel etc should do that.
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.
Whiteboard: [sg:want P4]
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.
Whiteboard: [sg:want P4] → [sg:want P5]
Flags: blocking1.9? → blocking1.9+
Flags: blocking1.9+ → blocking1.9-
Whiteboard: [sg:want P5] → [sg:want P5][wanted-1.9]
Note that I'm adding such a call in bug 393503. It doesn't get called for all the various plugin cases, however....
12 years ago
Depends on: 393503
Whiteboard: [sg:want P5][wanted-1.9] → [sg:want P5]
add to Keywords: privacy
The Tor Project / Electronic Frontier Foundation is paying to have this bug fixed. "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." Source: https://blog.torproject.org/blog/web-developers-and-firefox-hackers-help-us-firefox-4
Clearing the noms - old bug nominated for tracking without justification. Please be careful with flags.
tracking-firefox5: ? → ---
tracking-firefox6: ? → ---
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
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
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.