Closed
Bug 309524
Opened 19 years ago
Closed 12 years ago
Call ShouldProcess in all cases for <object>
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
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.
Comment 1•18 years ago
|
||
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]
Comment 2•18 years ago
|
||
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]
Updated•18 years ago
|
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Updated•17 years ago
|
Flags: blocking1.9+ → blocking1.9-
Whiteboard: [sg:want P5] → [sg:want P5][wanted-1.9]
Comment 3•17 years ago
|
||
Note that I'm adding such a call in bug 393503. It doesn't get called for all the various plugin cases, however....
Updated•16 years ago
|
Flags: wanted1.9+
Whiteboard: [sg:want P5][wanted-1.9] → [sg:want P5]
Updated•15 years ago
|
QA Contact: ian → general
Updated•14 years ago
|
Flags: blocking1.9.0.19?
Comment 4•14 years ago
|
||
add to Keywords: privacy
Updated•14 years ago
|
Flags: blocking1.9.0.19?
Comment 5•13 years ago
|
||
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
Updated•13 years ago
|
tracking-firefox5:
--- → ?
tracking-firefox6:
--- → ?
Updated•13 years ago
|
Flags: blocking1.9-
Comment 6•13 years ago
|
||
Clearing the noms - old bug nominated for tracking without justification. Please be careful with flags.
tracking-firefox5:
? → ---
tracking-firefox6:
? → ---
Assignee | ||
Comment 7•12 years ago
|
||
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 | ||
Comment 8•12 years ago
|
||
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
Assignee | ||
Comment 9•12 years ago
|
||
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
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•