Closed Bug 309524 Opened 19 years ago Closed 12 years ago

Call ShouldProcess in all cases for <object>

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla17

People

(Reporter: Biesinger, Assigned: johns)

References

Details

(Keywords: sec-want, Whiteboard: [sg:want P5])

<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?
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....
Flags: wanted1.9+
Whiteboard: [sg:want P5][wanted-1.9] → [sg:want P5]
QA Contact: ian → general
Flags: blocking1.9.0.19?
add to Keywords: privacy
Flags: blocking1.9.0.19?
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
Flags: blocking1.9-
Clearing the noms - old bug nominated for tracking without justification. Please be careful with flags.
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
Assignee: cbiesinger → jschoenick
Status: NEW → ASSIGNED
Depends on: 781126
No longer depends on: 393503
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
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.